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:
Doug Thayer 2021-11-28 21:47:04 +00:00
Родитель ab52fe7f54
Коммит 6e1905eb5e
1 изменённых файлов: 2 добавлений и 1 удалений

Просмотреть файл

@ -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();