APZCTreeManager::AdjustScrollForSurfaceShift is only called from the
compositor now, so there is no need to expose this API for callers in
widget code.
MozReview-Commit-ID: BySCQ8N4SuM
This should fix some wrong-looking code that computes the clip for
WebRenderDisplayItemLayer instances. As this code is not exercised very
much it's hard to know if this change is actually correct.
MozReview-Commit-ID: BSsBpBmzWgd
These functions also have built-in assumptions about the stacking
context structure mapping to the layer tree structure which are not
necessarily valid. So we remove these functions and update code that
uses them.
MozReview-Commit-ID: UkXXAF59qv
The only remaining callers of RelativeToParent() are in
StackingContextHelper itself, which we can remove now by having the SCH
take a parent SCH and use it instead of RelativeToParent(). This patch
implements this change.
This makes a failing test pass, because of how preserve-3d container
layers work. Specifically, preserve-3d container layers render their
descendants in z-order, not in tree order. If those children were assuming
that their parent had already pushed a stacking context, that assumption
may have been false because the parent might have not yet been rendered
because of z-ordering. By using the StackingContextHelper chain instead
of the layer tree ancestry, we fix the stacking-context-relative coordinates
being used in the descendant subtree of preserve-3d container layers.
MozReview-Commit-ID: HzZvBuAlMdB
This updates more code that was using RelativeToParent() to use the
stacking context helper's ToRelativeWr* functions instead. This get us
closer to breaking the assumption that the WR stacking context order maps
1:1 to the layer tree structure.
MozReview-Commit-ID: HQrbvCgPOW4
This propagates the StackingContextHelper to the rest of the code that
builds WR display items, because we will need it in future patches to
stop using RelativeToParent.
MozReview-Commit-ID: 3PlQrJRhH36
This cleans up WebRenderRefLayer::RenderLayer to use typed coordinate
systems and the StackingContextHelper. Note that this patch contains a
functional change, because the clip rect pushed no longer includes the
transform on the ref layer itself. It's not clear to me why we were doing
that, and didn't seem correct.
MozReview-Commit-ID: K7FoeLnXc56
This uses the StackingContextHelper and typed helper functions in
WebRenderLayer to simplify WebRenderTextLayer::RenderLayer. It also
removes the implicit assumption in WebRenderTextLayer that the parent
layer pushed a stacking context, which is an assumption we will
probably break in the future.
MozReview-Commit-ID: CARoGVQd56i
This is needed for the next patch, because the bullet frame WR rendering
code will need a StackingContextHelper to pass to the PushGlyphs call.
It also helps with some of the later patches in this series, when we get
rid of the RelativeToParent calls.
MozReview-Commit-ID: Is0aciHhy2N
This is needed in part 3 to update WebRenderTextLayer::RenderLayer, so
that it no longer assumes the parent container layer has pushed a
stacking context, and instead explicitly uses the StackingContextHelper.
MozReview-Commit-ID: 9twUmDgUipX
Need to pass the default transform/opacity to compositor if animations
exist because it is possible that gecko fails to get animated value
after animation sampling, like an animation with delay.
MozReview-Commit-ID: IK06hWvaSPf
Pass empty opacity(transform) in stacking context when there exists opacity(transform) animations and
the final opacity(transform) value will be resolved on the compositor after animation sampling
MozReview-Commit-ID: 6pF9Oe8Ks2I
First, hook the Layer's ClearAnimation API to delete unnecessary
animations in next layer transaction. Second, add another async
DeleteCompositorAnimations API to delete animations on the compositor,
especially calling this API before WebRenderLayerManager got destroyed.
MozReview-Commit-ID: 4mbj5IgsXYa
By passing the startTime as a TimeDuration we are able to represent times in the
distant past (and with the same range as we can represent on the main thread so
that if we do encounter range errors in future, they should not differ between
the main thread and the compositor).
This patch includes a crashtest. I have verified that, without the code changes
included in this patch, this crashtest fails on debug builds on OSX.
MozReview-Commit-ID: EDuKLzfEC0K
--HG--
extra : rebase_source : 1883080fdfac8c33f70698145f21e67cbdfdd4f2
In bug 1223658 we separated out the delay from the start time but we failed to
remove it from this calculation. As a result, when a pending animation begins it
will have the delay applied twice (once here, and once when it is sampled on the
compositor). This will happen until the layer is next updated.
This bug was not exposed by any existing tests since we don't use this code path
when the refresh driver is under test control. Furthermore, the one test that
was supposed to cover this was refactored in such a way that it stopped testing
this code path. That test is restored earlier in this patch series and enabled
in this patch.
MozReview-Commit-ID: B2KR7YaPsMK
--HG--
extra : rebase_source : 6c888252813fbfc01baf5d4bb1728d989ee1586c
Lee Salzman
Carsten "Tomcat" Book
Wes Kocher
David Anderson
Botond Ballo
Randall Barker
Kartikaya Gupta
Morris Tseng
peter chang
Jeff Muizelaar
Brian Birtles
gabriellesc
Ethan Lin