зеркало из https://github.com/mozilla/gecko-dev.git
Bug 1743304 - Semi-reduntantly propagate raster space inheritance in gecko r=gw
So, it turns out I didn't fully test the patch from bug 1740262 after I made my final changes to it. A change that I had in the patch which I thought was unnecessary, because it didn't fix the problem by itself, turns out to in fact be necessary. It turns out we still need to inherit the parent stacking context's `mRasterizeLocally` value inside gecko, or else we could have scale changes which get dropped on the WebRender side. I do think long term WebRender should handle all of this itself, because I believe there are still potential issues lurking here when we start to think of this across the process boundary, but I don't think I'm the right person right now to untangle everything to cleanly move everything necessary into WebRender, so I think the solution for right now is to have Gecko somewhat but not entirely reduntantly handle raster space inheritance itself, in addition to WebRender handling raster space inheritance in order to partially cover the process boundary case. This is not a pretty solution, but as far as I can tell it fixes the issues that bug 1730710 introduced without regressing the performance back to pre-1730710 levels. Differential Revision: https://phabricator.services.mozilla.com/D132308
This commit is contained in:
Родитель
ab52fe7f54
Коммит
6e1905eb5e
|
@ -133,7 +133,8 @@ StackingContextHelper::StackingContextHelper(
|
|||
: mBuilder(&aBuilder),
|
||||
mScale(1.0f, 1.0f),
|
||||
mDeferredTransformItem(aParams.mDeferredTransformItem),
|
||||
mRasterizeLocally(aParams.mRasterizeLocally) {
|
||||
mRasterizeLocally(aParams.mRasterizeLocally ||
|
||||
aParentSC.mRasterizeLocally) {
|
||||
MOZ_ASSERT(!aContainerItem || aContainerItem->CreatesStackingContextHelper());
|
||||
|
||||
mOrigin = aParentSC.mOrigin + aBounds.TopLeft();
|
||||
|
|
Загрузка…
Ссылка в новой задаче