The code in ComputeSuitableScaleForAnimation feeds its double-based
computation results into GetSuitableScale, which takes and returns
floats. Also the double-based computation that it's doing involves
calling UpdateMinMaxScale a bunch which explicitly uses the float
variant of std::min and std::max. And all of this is used from
ChooseScaleAndSetTransform which does other things like call a
"RoundToFloatPrecision" function, and casts the final values to
floats before setting the layer's prescale. So let's just use
floats all the way through.
MozReview-Commit-ID: BE3WC5hv89d
--HG--
extra : rebase_source : 987d9d69ec2a200ed68c59bae5fae1115713a94c
This code was written before the ScaleFactors() function was available on
the float-based gfx::Matrix, which I presume is why it was written to
convert the matrix to the double-based variant and store the scale as
doubles. We don't need to do that any more.
MozReview-Commit-ID: EoWLpny8g61
--HG--
extra : rebase_source : 4cac59121961bfb35359def042ac4b0200a85312
The code here feeds into gfxContext::mTransform which is float-based, so
using double-based rects and matrices here is unnecessary.
MozReview-Commit-ID: CbeMM8003DA
--HG--
extra : rebase_source : 735d5c880cca36b9e9bea6cb0c94825b6a1c4597
The core of this change is in gfxContext.*:
- change gfxContext::CurrentMatrix() and gfxContext::SetMatrix() to
return and take a Matrix respectively, instead of converting to
and from a gfxMatrix (which uses doubles). These functions therefore
will now match the native representation of the transform in gfxContext.
- add two new functions CurrentMatrixDouble() and SetMatrixDouble() that
do what the old CurrentMatrix() and SetMatrix() used to do, i.e.
convert between the float matrix and the double matrix.
The rest of the change is just updating the call sites to avoid round-
tripping between floats and doubles where possible. Call sites that are
hard to fix are migrated to the new XXXDouble functions which preserves
the existing behaviour.
MozReview-Commit-ID: 5sbBpLUus3U
As with the previous patch, instead of setting the override on the root
layer, we set the flag on the nsDisplayListBuilder before building the
display list, and the flag automatically forces all event regions
display items to use their dispatch-to-content region instead of any
other regions.
Both the WebRender and non-WebRender codepaths were setting the override
flag on their root layers and don't need to any more.
MozReview-Commit-ID: 1cz0ahqwkOm
--HG--
extra : rebase_source : 3292951aca97fd1a355c2fae5b0ab42d2064c548
The mechanics of this change is fairly straightforward - instead of setting the
override on the layer corresponding to the in-process subdocument, we just set
the flag on the display list builder; that flag is already checked when building
the layer event regions for descendant nsIFrames.
As a side-effect, we also don't need to force a layer for in-process subdocuments
just because they have document-level APZ-aware listeners. One of reasons we were
doing so before was so that we would have a layer to stash the override flags on
but now we don't need that any more.
Note that out-of-process subdocuments are not affected; for those cases
the nsSubDocumentFrame delegates BuildDisplayList to
RenderFrameParent/nsDisplayRemote, which will still set the overrides on
the RefLayer that is created.
MozReview-Commit-ID: DZWglE4e62p
--HG--
extra : rebase_source : 78494a5cbfd0dfecb5f2262e5c1b3dc5367c5d55
The code previously used GetClippedBoundsWithRespectToASR() (changed
in bug 1298218), but this violated the requirements of nsDisplayList::
ComputeVisibilityForSublist().
MozReview-Commit-ID: F9UVMvVKLAp
--HG--
extra : rebase_source : ec188650070d4e8de1b19395c3ed6f31e7d0e04f
We allow an nsDisplayMask item to satisfy the requirement even it does not
itself have a clip, as long as its children have finite bounds with respect
to the ASR.
MozReview-Commit-ID: 8zKE0bguY38
--HG--
extra : rebase_source : 74baaea2647708d1cd024f9e6afd82508e95c74a
We need to get the offset across documents boundaries, since the scrollframe
might be inside a subdocument. In such cases we were previously computing
a (incorrect) zero offset for the scrollframe, which was throwing off the
margin for the sticky items inside the scrollframe.
MozReview-Commit-ID: AWeQ9ay2cmp
--HG--
extra : rebase_source : 7dd8eda26c482cc359042d79073740524efa792a
The only thing we use the PresContext for is the app units. I'd rather not
worry about keeping around a PresContext for the webrender display item
grouping.
There are cases where we do a main-thread paint at a scroll position
where sticky offsets have been applied in order to keep sticky items
visually unmoving. From that paint, it's possible to do an async-scroll
in the direction that reduces the sticky offset. In order for WR to
handle this case properly we need to tell WR how much of a sticky offset
was already applied on the main thread.
MozReview-Commit-ID: 79DsfPpsIfA
--HG--
extra : rebase_source : e39316702cff3bd4ee6721c7503a1a9267734cd8
If the scrollframe has no ASR and is not async scrollable, WR will never
need to adjust the position of the sticky item. So we don't actually
need to send this data to WR. In theory this would be harmless but the
later patches in this bug actually expose another coordinate space
mismatch between the gecko and WR sticky-position code, so this patch is
needed to avoid the latent problem from manifesting to the user.
MozReview-Commit-ID: J0LMcU1FudA
--HG--
extra : rebase_source : 434ece364e6c793707e5a4a18008e4697096b0fd
And unthrottle them on every 200ms just like we do for transform animations on
the compositor. To unthrottle the transform animations properly, we need to
update UpdateLastTransformSyncTime each time we compose the style for the
animations instead of updating it when we send the transform animation to the
compositor. That's because display item for transform is built even while we
are throttling the transform animations for some reasons, so if we updated the
last transform sync time there, the time will not match what it should be.
MozReview-Commit-ID: GwMzJqUlzd2
--HG--
extra : rebase_source : 09e379191970687a9f35aead871acf450c63813e
Bug 1393383 already added support for these kinds of display items (where the
border radii are not all the same) to the BuildWebRenderCommands function, but
for some reason CanBuildWebRenderCommands was left untouched and so we do
a fallback for these items when we can support them just fine.
MozReview-Commit-ID: GOAaQMfF2YQ
--HG--
extra : rebase_source : f5f7a87483347e97b5b95dd535c5497d355aebf3
