Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sync changes from mozilla-central gfx/wr #3944

Merged
merged 2 commits into from May 11, 2020
Merged

Conversation

@moz-gfx
Copy link

moz-gfx commented May 11, 2020

No description provided.

Glenn Watson added 2 commits May 11, 2020
… r=Bert

The public clip API allows clips to be defined with either
a parent hierarchy, or via a clip-chain display item where
a list of clips are provided.

The WR internals represent both of these as an internal
clip-chain, where clips are parented and stored in a
linked list (although the elements themselves are in
a contiguous array).

Previously, WR would convert the public clip nodes into
clip-chains as soon as the clips were defined. However,
this complicates many other parts of the code. For example,
we want to be able to re-parent clips to the root clip
node of an iframe, and we need to extract shared clips
that can be handled by parent surfaces.

With this change, clips defined in the public API are
mapped into a ClipTemplate. The internal clip-chains
that WR uses are not created until the primitive is
defined. With this change, we can easily insert or
modify how the primitive's clip-chain is created. In
this patch, the `ClipChainBuilder` is used to add
the iframe clip root to any primitives inside the
iframe. In future patches, it will also be used to
handle clips from redundant stacking contexts, which
will allow the removal of all the Push/PopClipChain
display items.

Differential Revision: https://phabricator.services.mozilla.com/D74347

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/5313bc3ed301224926fcf1c116e5c9d1d983b5de
Previously, the spatial node index for a clip was stored as part
of the interning key.

However, if a new display list is sent where the clip has the same
transform, but the shape of the spatial-tree had changed (e.g.
due to a new transform being inserted due to a DOM change), this
could result in those clip(s) being detected as different. This
can cause unnecessary invalidations of picture cache tiles.

With this patch, the spatial node index is stored inside the
instance structures (ClipInstance and ClipChainNode), meaning that
picture cache tiles are no longer invalidated if the spatial
tree shape changes.

Differential Revision: https://phabricator.services.mozilla.com/D74363

[ghsync] From https://hg.mozilla.org/mozilla-central/rev/22227ba866f7e720947856905d092242cfc8f8f0
@moz-gfx
Copy link
Author

moz-gfx commented May 11, 2020

@bors-servo r=auto

@bors-servo
Copy link
Contributor

bors-servo commented May 11, 2020

📌 Commit 197993b has been approved by auto

@bors-servo
Copy link
Contributor

bors-servo commented May 11, 2020

Testing commit 197993b with merge 15a8939...

@bors-servo
Copy link
Contributor

bors-servo commented May 11, 2020

☀️ Test successful - status-taskcluster
Approved by: auto
Pushing 15a8939 to master...

@bors-servo bors-servo merged commit 15a8939 into servo:master May 11, 2020
2 of 3 checks passed
2 of 3 checks passed
continuous-integration/appveyor/pr AppVeyor build failed
Details
Community-TC (pull_request) TaskGroup: success
Details
homu Test successful
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

2 participants
You can’t perform that action at this time.