This required replacing nsDisplayListBuilder::mSVGEffectsBuildingDepth with
a stack of the SVG effects frames that we're currently building inside.
Depends on D46063
Differential Revision: https://phabricator.services.mozilla.com/D46064
--HG--
extra : moz-landing-system : lando
The current code needs to handle incomplete draws already due to async decoding,
and this prevents the race condition where we paint between the size-available
and load notifications, as the CSS image loader only invalidates for the first.
Once we try to decode the image at least once, then we'd repaint properly from
ImageLoader::OnFrameComplete.
Differential Revision: https://phabricator.services.mozilla.com/D41006
--HG--
extra : moz-landing-system : lando
We always define it to the same thing, and we're inconsistent in whether
we use `CPP_THROW_NEW` or `throw()`, so we might as well just use the
standard C++ thing and get rid of some baggage.
Differential Revision: https://phabricator.services.mozilla.com/D40425
--HG--
extra : moz-landing-system : lando
Not sure if we need this, but the window dragging regions have it, so in case we need to turn off retained display lists we have this and there will be no difference to before the patches in this bug.
Depends on D38589
Differential Revision: https://phabricator.services.mozilla.com/D38590
--HG--
extra : moz-landing-system : lando
For retained display lists it needs to be a weak frame region to areas get removed for modified frames and the rest stick around.
Each display item can contribute an opaque region but WeakFrameRegion can only track one rect per frame. It turns out that we only return rects from GetOpaqueRegion except in one hit testing case.
This still means more than one display item per frame could be contributing to the opaque region, we would miss the second and further rects in that case.
Differential Revision: https://phabricator.services.mozilla.com/D38589
--HG--
extra : moz-landing-system : lando
This distinguishes better between the overloaded aspect of the PerFrameKey and the
actual mixed value.
Differential Revision: https://phabricator.services.mozilla.com/D37804
--HG--
extra : moz-landing-system : lando
This static method is assumed to have the same signature as the type's constructor,
and so we must have an implementation of ComputePerFrameKey for each constructor
a display item provides that is called by MakeDisplayItem. Notably this excludes
the MakeClone constructor for a lot of items.
There is a default varargs implementation on nsDisplayItem which everyone
inherits by default, so types which previously didn't overload this method
still don't need to.
Providing an implementation of ComputePerFrameKey on some display item type
shadows the varargs implementation, so one doesn't need to worry about overloading
one constructor but forgetting about another -- if you do, the compiler will only
see the overload and complain that the signature doesn't match.
One slightly annoying result of this is that display items which previously
inherited an overloaded implementation from a superclass now must provide
their own manual implementations. Although as far as I could tell, all of
those cases had a trivial implementation of key=0 (the super class supported
custom keys but the subclasses didn't make use of it).
In those cases I just hardcoded key=0, but it's possible that it would be
better to call into the superclass' implementation to be more robust to changes.
Differential Revision: https://phabricator.services.mozilla.com/D37803
--HG--
extra : moz-landing-system : lando
Also move the impl to the .cpp file to avoid expensive rebuilds when it
is modified.
Differential Revision: https://phabricator.services.mozilla.com/D37589
--HG--
extra : moz-landing-system : lando
I missed in bug 1487216 that the pres arena memory reporting assumes that the
entry indices are frame class ids, which means that we're reporting some display
list arena entries as frames, which is obviously wrong.
Cleanup a bit nsPresArena to remove the custom id concept, and report also
individual display item type memory usage.
Differential Revision: https://phabricator.services.mozilla.com/D35368
--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
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
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
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
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
This also changes behaviour a bit, previously we interleaved column and column group backgrounds. where we now put all the column group backgrounds behind all columns.
I believe this is the correct ordering as per CSS2.2 Appendix E.
Column backgrounds can overlap when using 'span', and we now render this in a different order, but this matches what other browsers do.
Differential Revision: https://phabricator.services.mozilla.com/D29278
--HG--
extra : moz-landing-system : lando
In bug 1527182 we made it so that APZ can directly drag-scroll scrollframes
that are inside SVG effects, because that's possible with WR on the compositor.
However the code changed in that bug was meant to be kept in sync with
a second piece of code. The second piece of code controls the generation
of ScrollInfo items for scrollframes inside SVG effects - since we can
APZ-scroll them with WR, we don't need the scrollinfo item anymore.
Producing the scrollinfo item was changing the structure of the APZ tree
in terms of where the transform ended up, and was causing badness with
untransforming the drag mouse events.
This patch adds a test that covers the scenario and also corrects the defect
by bringing the two bits of code back in sync.
Differential Revision: https://phabricator.services.mozilla.com/D31647
--HG--
extra : moz-landing-system : lando
This avoids the expensive conversion, and cleans up a bunch.
Further cleanup is possible, just not done yet to avoid growing the patch even
more.
Differential Revision: https://phabricator.services.mozilla.com/D30748
--HG--
extra : moz-landing-system : lando
Please advise if there is a better alternative. After ensuring that
extension popups are wired up to create an nsDisplayRenderRoot, the
bottom bit of the popup's content is cut off. This fixes that issue,
but I'm not certain if it is the most robust option.
Differential Revision: https://phabricator.services.mozilla.com/D31007
--HG--
extra : moz-landing-system : lando
Bogdan Tara
Morgan Reschenberg
Botond Ballo
Brindusan Cristian
Miko Mynttinen
Emilio Cobos Álvarez
Connor Brewster
Nathan Froyd
Timothy Nikkel
Alexis Beingessner
Sylvestre Ledru
Kartikaya Gupta
Doug Thayer
Matt Woodrow
Cosmin Sabou
Noemi Erli
Ryan Hunt
Oana Pop Rus