With retained display lists, a content render root might get marked as not
needing a build, in which case the nsDisplayRenderRoot::CreateWRCommands
function does an early exit. In this case, we don't mark the associated
WebRenderUserData as used during the display list build, which causes it to
get deleted at the end of the transaction. The next transaction that
doesn't early-exit will re-create the WebRenderUserData with a new boundary
object. The compositor therefore thinks it's a brand new thing and, if
conditions are right, could end up destroying and re-creating much of the
APZC tree. That in turn can have effects like discarding paint-skipped
scrolling.
This patch ensures we always touch the WebRenderUserData during the display
list build, so we don't discard it. This problem may still affect nested
nsDisplayRenderRoot instances but I don't think we ever cases where those
occur.
Depends on D36386
Differential Revision: https://phabricator.services.mozilla.com/D36387
--HG--
extra : moz-landing-system : lando
If we decide to just go with an overlay that sits fully over the
window (which I don't personally see a perf problem with right now,
but correct me if you can think of one), then this should be all
we need.
Differential Revision: https://phabricator.services.mozilla.com//D33819
--HG--
extra : rebase_source : 44a5af47f9c10071b0933931fbf3708978f549e4
The patch also removes the layers.mlgpu.enable-container-resizing pref, because
it's dead.
Differential Revision: https://phabricator.services.mozilla.com/D36159
--HG--
extra : rebase_source : e215d584aed18f865d2e8d00a78e76e9b0323e6e
This restores our previous and per-spec behavior. Comparing only ratios was not
correct in the case one of the dimensions was zero and thus not scaled.
Differential Revision: https://phabricator.services.mozilla.com/D35571
--HG--
extra : moz-landing-system : lando
This changes CreateClippedDrawTarget so that instead of taking
a max size and a transform it just takes a user space rect of
the desired bounds.
This change allows the caller to not worry about the computing
a max size based on the current clip. Instead this responsibility
is lowered into the specific backends.
The main motivation for this work is to allow blob recoordination
to create recordings that don't depend on the current clip.
Some additional benefits are that the API is easier to use and
as can be seen simplifies the SVG masking code because it doesn't
need to track surface offsets manually.
It's also an important step towards removing all the uses of
gfxContext::GetClipExtents which will let us get rid of the separate
clipping stack in gfxContext and help us move off of gfxContext
completely.
Most backend implementations of CreateClippedDrawTarget are relatively
simple. DrawTargetCapture is modified to track the current clip rect
so that it can create a new DrawTargetCapture of the appropriate size
without needing to worry about lazy resolution.
Differential Revision: https://phabricator.services.mozilla.com/D33363
--HG--
extra : moz-landing-system : lando
This changes CreateClippedDrawTarget so that instead of taking
a max size and a transform it just takes a user space rect of
the desired bounds.
This change allows the caller to not worry about the computing
a max size based on the current clip. Instead this responsibility
is lowered into the specific backends.
The main motivation for this work is to allow blob recoordination
to create recordings that don't depend on the current clip.
Some additional benefits are that the API is easier to use and
as can be seen simplifies the SVG masking code because it doesn't
need to track surface offsets manually.
It's also an important step towards removing all the uses of
gfxContext::GetClipExtents which will let us get rid of the separate
clipping stack in gfxContext and help us move off of gfxContext
completely.
Most backend implementations of CreateClippedDrawTarget are relatively
simple. DrawTargetCapture is modified to track the current clip rect
so that it can create a new DrawTargetCapture of the appropriate size
without needing to worry about lazy resolution.
Differential Revision: https://phabricator.services.mozilla.com/D33363
--HG--
extra : moz-landing-system : lando
visibleRect should affect both WR/layers, and scaling will only affect
layers.
Differential Revision: https://phabricator.services.mozilla.com/D34525
--HG--
extra : rebase_source : 49273db3e10088c9493f693d5f8b58864dcb01aa
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
For now I added everything to the same bucket, but I wrote this so it should be
easy to add more buckets as needed (either to mArenaSizes, or more specific ones
like the style system has). But this is probably enough for now.
Differential Revision: https://phabricator.services.mozilla.com/D34126
--HG--
extra : moz-landing-system : lando
This preserves the APZ invariant that if there is an async zoom container,
then the RCD-RSF scroll metadata is on the same layer or descendant layers.
Differential Revision: https://phabricator.services.mozilla.com/D34255
--HG--
extra : moz-landing-system : lando
Previously we computed a caret frame each time we started display list building for a pres shell, and tracked a stack of these as we descended through subdocuments.
This meant that we couldn't know if the caret frame had changed before we started building, and we instead had to support invalidations in the middle of building.
Since there should only ever be one focused document, we can instead retrieve this from the focus manager, and find the sole caret frame for all documents we want to paint.
Differential Revision: https://phabricator.services.mozilla.com/D33880
--HG--
extra : moz-landing-system : lando
Not only animating transform-like properties, but also non-animating ones have
to be passed into the compositor, so the final transform matrix could
take them into account (on the compositor).
Differential Revision: https://phabricator.services.mozilla.com/D33580
--HG--
extra : moz-landing-system : lando
nsDisplayRemote no longer has any direct ties to RenderFrame and should
be moved to nsSubDocumentFrame.cpp where it's actually used/created.
Differential Revision: https://phabricator.services.mozilla.com/D33563
--HG--
extra : rebase_source : ae2e03108820bd14b5f2771da17cabfd95706f94
extra : source : b301161ab461cd46cea3f91749896686c50e9b9f
extra : histedit_source : 1c80f83d26734e56bd6353f0a50dcbc4bf894b4b
WebRender support will be finished in the following commit.
Differential Revision: https://phabricator.services.mozilla.com/D32476
--HG--
extra : rebase_source : f40ab9946e946d137aa2522f9fce0aa268e22937
extra : intermediate-source : ea63d3d6b85fd3c4456275638e968e0eed045b37
extra : source : 79be6c27e0f9e262b75723c120786e2256ee4700
Not using blob invalidation is broken. Having this pref accidentally
flipped has wasted multiple people's time.
Differential Revision: https://phabricator.services.mozilla.com/D33327
--HG--
extra : moz-landing-system : lando
I think this is a good change regardless of other discussion in bug 1552587. If
we decide to move `mColor` to the top-level of the struct that can be done
separately.
Differential Revision: https://phabricator.services.mozilla.com/D32726
--HG--
extra : moz-landing-system : lando
We clear mGlassDisplayItem before a full display list build. We use it so that we only mark the first glass item we encounter with the glass item flag.
For partial builds we use the bool mHasGlassItemDuringPartial to track the same thing, so we only mark one item as glass. Merging handles updating mGlassDisplayItem for partial builds.
So this means that we could have one item marked as a glass item in the old list and one item marked as a glass item in the new list.
If merging doesn't use the existing mGlassDisplayItem then it clears mGlassDisplayItem. If merging uses a new item that is a glass item it calls SetGlassDisplayItem on it, so it will only become the new glass item if there wasn't one there already.
So it is actually possible that both items with the glass flag make it into the final display list. Thus the number of display items in the display list with the glass flag can grow to any number, but it would have to be a very very weird state because the glass item is only allowed to be a themed background item coming from a doc element box frame (one per xul doc near the root).
Differential Revision: https://phabricator.services.mozilla.com/D32558
--HG--
extra : moz-landing-system : lando
Kartikaya Gupta
Doug Thayer
Nicholas Nethercote
Coroiu Cristina
Charlie Marlow
Ryan Hunt
Matt Woodrow
Brindusan Cristian
Emilio Cobos Álvarez
Jeff Muizelaar
Narcis Beleuzu
Andreea Pavel
Oana Pop Rus
Peter Van der Beken
Boris Zbarsky
Cosmin Sabou
Bas Schouten
Botond Ballo
Noemi Erli
Boris Chiou
Miko Mynttinen
shindli
Timothy Nikkel