A basic sanity check here seems to produce the correct behaviour but I'm
not at all confident that this will always do the correct thing in more
complex cases or when perspectives are involved. However this is hard to
test and get working without the testing infrastructure up and running
so I'd rather land this simple code first and then dig into the more
complex cases once we have a way to catch regressions.
MozReview-Commit-ID: E4HytiZowEn
--HG--
extra : rebase_source : c7466092298aebf66926e8e0bdf58eb4651f0f19
Put mEffectsBounds in nsDisplyaSVGEffect does not really make sense, since only
nsDisplayFilter need it.
MozReview-Commit-ID: KSvDspZJcMP
--HG--
extra : rebase_source : 9d2f994b40e82e7146358932fbebbc60a4ca01c6
extra : source : cfd8d564c0198239eb029e4984d75a692bd9f9ca
We need to create a WebRenderAnimationData item in order to preserve the
animation id on the frame - this allows to re-use the same animation id
over multiple display list building phases.
MozReview-Commit-ID: 5Uj5sv6FUgt
Instead of the WebRenderLayerScrollData code knowing about all the
different display item types, it makes more sense to move this logic
into the display items.
In addition to avoiding dis-encapsulating the data from nsDisplayItem subclasses,
this makes it easier to handle two specific scenarios:
(1) the case where an nsDisplayItem A subclasses another nsDisplayItem B, but A
and B have different types returned by GetType(). Previously A and B would have
to be handled explicitly in the WebRenderLayerScrollData switch statements,
which doesn't scale well if new types are added. With the new approach the
virtual function is shared down from A to B and so takes care of it. This is
particularly relevant for types like nsDisplayOwnLayer which have a number of
subclasses.
(2) the case where a display item *might* have APZ-relevant information.
In this case the type of the item alone is not sufficient to determine
if we need to create a new WebRenderLayerScrollData for it. Instead, we
need to access specific state inside the display item. This is now
handled by the UpdateScrollData function returning true when passed
nullptr arguments, and replaces the switch statement in
WebRenderLayerManager that updated forceNewLayerData.
MozReview-Commit-ID: FlfHlgSccSn
--HG--
extra : rebase_source : d1fe841724cc6020433aea31ffb5214d8a44d0a9
Call gfxPrefs::LayersAllowTextLayers before aBuilder->GetWidgetLayerManager,
which is costly. Since LayersAllowTextLayers returns false by default, we are
free of using aBuilder->GetWidgetLayerManager.
MozReview-Commit-ID: Jv1voPYjOad
--HG--
extra : rebase_source : b4892a8800d71eeac5f30b8425954505cade31e6
For gmail, 100 is too small, enlarge the dafault capaicty of
nsDisplayListBuilder::MarkFramesForDisplayList to prevent reallocation.
MozReview-Commit-ID: 5zSxyakZ5O9
--HG--
extra : rebase_source : a20032ef98fc0e78ddbd4ac8194ee4f11c2e11a7
extra : source : 105804994e32827ff87ea7fcacecf942df41a051
The reason of this change is the same as for Part 2, except this commit fixes
nsSVGMaskFrame::GetMaskForMaskedFrame rather than PaintSVG.
MozReview-Commit-ID: DS0eG6eKDgs
The DrawResult return was not in fact anything to do with the success or
failure of that method, but was actually passing out a very specific piece of information
about the success or failure of any imagelib drawing that may not have occurred
under the various PaintSVG calls.
The signature of PaintSVG is changed from
DrawResult PaintSVG(...., uint32 flags);
to
void PaintSVG(...., imgDrawingParams& aPackage);
imgDrawingParams wraps DrawResult and imgIContainer::FLAG_* as a pack, pass through
PaintSVG to imagelib draw calls under beneath.
MozReview-Commit-ID: IOq2evUAOQF
Kartikaya Gupta
Morris Tseng
Matt Woodrow
Sebastian Hengst
Ehsan Akhgari
cku
Ethan Lin
Wes Kocher
Ryan VanderMeulen
Nicolas Silva
Alexis Beingessner
Botond Ballo
Jonathan Kew