This changes the serialization format a little bit.
We now have an index at the end of the blob. This
is currently used to store a list of the used font keys.
In the future we'll add rects and can use it for invalidation.
This extends the fix in bug 1373802 to account for extra levels of
display item nesting. If those extra intermediate display items don't
push any clips we still want to pick up the ClipAndScroll from the
enclosing ancestor that has it.
MozReview-Commit-ID: AmxRz4fBKnX
--HG--
extra : rebase_source : ae12a9f797ab201169ff199d0d42a29df51ee1cb
We already support cases where we have scrolling clips applied to fixed
items. However if we had to build nested clips inside those items, then
those nested clips would not properly inherit from the scrolling clips.
This patch addresses that case.
MozReview-Commit-ID: CWp1x0EsyaP
--HG--
extra : rebase_source : f8c80ace2da39edebaabd5339670a68038a18489
The window buttons are drawn as part of the AddWindowOverlayWebRenderCommands
function which is invoked in the full-transaction codepath. It should be possible
to have the empty transaction codepath simply update the image (without building
a full WR display list) and do a recomposite. That would be more performant but
it requires some plumbing to build and ship across a IpcResourceUpdateQueue on
empty transactions.
MozReview-Commit-ID: 2Mrb0wELD6E
--HG--
extra : rebase_source : 9a94c32f94403050835bf3445176f4fe2c1579fa
This is functionally unrelated to the bug but I noticed it while fiddling with
the code, and the lines affected are kind of intertwined with the next patch so
I'm just doing the code removal as part of this bug.
MozReview-Commit-ID: CwmluhyCdbR
--HG--
extra : rebase_source : 0a86ba7299f63587b77c44fadc804e34ada5a474
We want to always use Servo animation backend on the compositor.
However, Android doesn't support Stylo now, so add a defined flag for it.
MozReview-Commit-ID: 63MnTBnq6yv
--HG--
extra : rebase_source : dce46737f81e4e217e9fd67b6bec722994dca6a2
Use the new added FFI, Servo_ComposeAnimationSegment, to compose an
animation segment from Servo backend on the compositor.
MozReview-Commit-ID: LNgpCSIlDl9
--HG--
extra : rebase_source : 5b5c145fae877b4f4b01ea54259737dc9dad2951
We will use Servo backend on the compositor, so implement this for opacity.
MozReview-Commit-ID: BeWR2nBSbjb
--HG--
extra : rebase_source : eb5db3cf04640a83f13857984e792a949f26bcc7
My original understanding of the API was flawed, and so while I had
position:sticky working in some cases it didn't work properly in a lot
of other cases. This patch corrects the usage of the API to match what
WR is expecting and fixes a lot of test cases.
MozReview-Commit-ID: AdMux19Fk9U
--HG--
extra : rebase_source : e7f970a710b2079501a91eeeac8c292b603210dc
Most of this change is just fiddling with function signatures so that they take
a LayerManager* instead of a Layer* (or in some cases, both). This allows
the WebRender codepaths to pass a WebRenderLayerManager* instead of having to
produce a Layer* which it doesn't have.
MozReview-Commit-ID: Fb0C8OUVDin
--HG--
extra : rebase_source : e4c3324cfa20c295db85d5c09df8d8d77865bb6a
Instead of unconditionally pushing and popping clips per display item,
this patch changes things so that for each recursive display list, we
create an ItemClips struct. We push this onto the stack when we enter
the display list, and pop it off at the end. For each display item, we
check to see if the clips would actually change compared to the previous
display item, and only do the pop/repush in that case.
MozReview-Commit-ID: J0MCc2V9hWT
--HG--
extra : rebase_source : 8617cfaa7391457867f01c1b619cb871a21bf3f5
This makes ScrollingLayersHelper a non-RAII type class, and instead adds
methods to notify it of when we start processing a new transaction or a
new display item within the transaction. This patch has no functional
changes, it's non-obvious refactoring.
MozReview-Commit-ID: GEZzCGbVqB1
--HG--
extra : rebase_source : dd4fab7f34da7c5465ba474db670cf583e8dadf4
Storing the per-item clip state in a struct like this will allow us to
easily compare the desired clip state across items, so we can avoid
doing unnecessary work when going from one item to the next. This patch
has no functional changes, it's just refactoring.
MozReview-Commit-ID: GX2FX4YDusO
--HG--
extra : rebase_source : 06d7bae5cbae99d2987881f26f7ebd26965c1799
Instead just keep a ref to it as a member variable. No functional
change.
MozReview-Commit-ID: 9jSBdZRIGuV
--HG--
extra : rebase_source : cd1b2f500e9a833f7d42bce53bdaec2118e0d4c3
Instead of unconditionally pushing and popping clips per display item,
this patch changes things so that for each recursive display list, we
create an ItemClips struct. We push this onto the stack when we enter
the display list, and pop it off at the end. For each display item, we
check to see if the clips would actually change compared to the previous
display item, and only do the pop/repush in that case.
MozReview-Commit-ID: GadIp2J8TrA
--HG--
extra : rebase_source : ba64c6b4659b8e51cab19b807088b9a50d71b85a
This makes ScrollingLayersHelper a non-RAII type class, and instead adds
methods to notify it of when we start processing a new transaction or a
new display item within the transaction. This patch has no functional
changes, it's non-obvious refactoring.
MozReview-Commit-ID: 3yq9sPiHMge
--HG--
extra : rebase_source : 286423f56de59211e320f015cb1004a1e98332b8
Storing the per-item clip state in a struct like this will allow us to
easily compare the desired clip state across items, so we can avoid
doing unnecessary work when going from one item to the next. This patch
has no functional changes, it's just refactoring.
MozReview-Commit-ID: 49B6hmsWZ4V
--HG--
extra : rebase_source : 8ac4bbf039f81bc2d26e92924ed041fa3d18e5ba
Instead just keep a ref to it as a member variable. No functional
change.
MozReview-Commit-ID: 5fccUlSifsA
--HG--
extra : rebase_source : a14672f926c383354db76e553ae23613fe4a432a
One of the sticky-pos tests was only passing because of two wrongs that
cancelled each other out in the old code. Specifically, instead of
defining a nested clip with the sticky clip as an ancestor, the clip was being
defined with the root ASR as an ancestor. Both resulted in the nested
clip not scrolling with the actual scrolling scrollframe and so the test
was passing.
The new code changes things so that the nested clip is defined with the
actual scrolling scrollframe as the ancestor, causing the reftest to fail.
Fixing the clip ancestry is not hard but it reveals other problems so
so I'm deferring that to a follow-up bug.
MozReview-Commit-ID: DldAKi1AP4l
--HG--
extra : rebase_source : a448e06fd26fff21bbc4a6f50e04dbbdb427298c
This handles some cases where a nested display item's clip chain
implicitly extends from the wrapper item's clip chain.
MozReview-Commit-ID: DmghxOWi81K
--HG--
extra : rebase_source : 8ec95df64fed247650baf8f5e0c868d1934aa6bc
Bug 1409442 is tracking a change that will allow scroll layers to have
multiple ancestors. Without that, there are cases we cannot properly
handle, and so we need to ignore a clip in those scenarios. This patch
makes sure we do that instead of crashing.
MozReview-Commit-ID: 7AU4uyzT6if
--HG--
extra : rebase_source : d483c2a7ecff5cd488a53fa5e6b6da55cc3a1e29
When display items (such as mask items) push an out-of-band clip, we
can't use clip ids from, or update clip ids into, the cache. We also
need to ensure we take these out-of-band clips into account when
determining the parent for a new clip we are going to define.
MozReview-Commit-ID: GcUI2Hf6SLB
--HG--
extra : rebase_source : 512be5a6998b9c1d6db9d8c550231f0883d721c9
This code is more straightforward in its recursion than the old code,
and provides a relatively clean way to explicitly pass the desired
parent when defining a new clip or scroll layer.
Refer to the documentation in the patch for more details.
Note that this patch provides the basic recursive algorithm to define
the clips and scroll layers, although it omits some of the complicating
edge cases which will be added in later patches. The new code is not
invoked from anywhere until all the edge case handling has been done.
MozReview-Commit-ID: 7z51Kd7LlPU
--HG--
extra : rebase_source : 491efac9282a7379f7977a1bc0205ac70e356c3c
The APIs now allow providing the parent clip or scroll info explicitly
instead of having to push it on the stack. For now we just pass
Nothing() to preserve the existing behaviour, so this change is a
functinoal no-op.
MozReview-Commit-ID: dtNamN595
--HG--
extra : rebase_source : 3b6bd03b919bd31cd89e3f82283cb962f8f6abc5
