-
Notifications
You must be signed in to change notification settings - Fork 279
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
Remove most use of the local prim rect by primitive templates. #3381
Conversation
The current picture caching code invalidates cached regions more than expected, due to how gecko handles scroll offsets. If a display list is received, then a scroll event occurs, and then a new display list is sent, the local rects will contain different coordinates, since the scroll offsets are baked into the local rects rather than in the scroll / reference frames. This results in primitives being interned with a different value, and cached surfaces being incorrectly invalidated. Since the way this works is non-trivial to change in Gecko, we need to handle this in WR. If we change primitive and clip keys and templates to store their rectangles in a true local primitive space (where the origin is always zero) then the interning will work as expected. To do this, we'll store the origin of a primitive in the instance, and only the size in the template. A side benefit of this approach is that test cases like dl_mutate will become much faster, since the only difference between the thousands of rectangles is the origin. This will effectively allow true instancing of primitives with common data. This is the first step towards that - by removing reliance of the primitive local rect from the primitive template code. The rest will be done as a series of incremental patches.
Why isn't a scroll just changing a transform property binding without re-sending the DL or affecting the local rects? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A few concerns, otherwise LGTM
prim_rect, | ||
[0.0; 4], | ||
); | ||
} | ||
PrimitiveTemplateKind::LinearGradient { ref brush_segments, .. } | | ||
PrimitiveTemplateKind::RadialGradient { ref brush_segments, .. } => { | ||
for segment in brush_segments { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it fine to still be writing the full rects for the segments?
@@ -586,7 +586,7 @@ impl AlphaBatchBuilder { | |||
}; | |||
|
|||
let instance = PrimitiveInstanceData::from(BrushInstance { | |||
segment_index: 0, | |||
segment_index: INVALID_SEGMENT_INDEX, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this unrelated? Are we changing this segment index at some later point?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reviewable status: 0 of 2 files reviewed, 2 unresolved discussions (waiting on @kvark)
webrender/src/batch.rs, line 589 at r2 (raw file):
Previously, kvark (Dzmitry Malyshau) wrote…
Is this unrelated? Are we changing this segment index at some later point?
INVALID_SEGMENT_INDEX is a sentinel value that tells the brush shader code to use the prim rect in the header, and that there is no segments in the trailing GPU cache data.
webrender/src/prim_store.rs, line 1190 at r2 (raw file):
Previously, kvark (Dzmitry Malyshau) wrote…
is it fine to still be writing the full rects for the segments?
No, that needs to change too. My plan is to make them zero-based (relative to the primitive instance origin) in a follow up patch to this.
@bors-servo r=kvark |
📌 Commit 3f30831 has been approved by |
Remove most use of the local prim rect by primitive templates. The current picture caching code invalidates cached regions more than expected, due to how gecko handles scroll offsets. If a display list is received, then a scroll event occurs, and then a new display list is sent, the local rects will contain different coordinates, since the scroll offsets are baked into the local rects rather than in the scroll / reference frames. This results in primitives being interned with a different value, and cached surfaces being incorrectly invalidated. Since the way this works is non-trivial to change in Gecko, we need to handle this in WR. If we change primitive and clip keys and templates to store their rectangles in a true local primitive space (where the origin is always zero) then the interning will work as expected. To do this, we'll store the origin of a primitive in the instance, and only the size in the template. A side benefit of this approach is that test cases like dl_mutate will become much faster, since the only difference between the thousands of rectangles is the origin. This will effectively allow true instancing of primitives with common data. This is the first step towards that - by removing reliance of the primitive local rect from the primitive template code. The rest will be done as a series of incremental patches. <!-- Reviewable:start --> --- This change is [<img src="https://reviewable.io/review_button.svg" height="34" align="absmiddle" alt="Reviewable"/>](https://reviewable.io/reviews/servo/webrender/3381) <!-- Reviewable:end -->
It is. However, if you scroll in a way that adjusts the scroll transform (as above), then do something that triggers Gecko to send a new DL (e.g. hover over an element that highlights), then Gecko will send a new DL where the current scroll offsets are baked into the local primitive rects, rather than a scroll frame. 😞 |
☀️ Test successful - status-appveyor, status-taskcluster |
…34afd7c3ca95 (WR PR #3381). r=kats servo/webrender#3381 Differential Revision: https://phabricator.services.mozilla.com/D13724 --HG-- extra : moz-landing-system : lando
…34afd7c3ca95 (WR PR #3381). r=kats servo/webrender#3381 Differential Revision: https://phabricator.services.mozilla.com/D13724
The current picture caching code invalidates cached regions more
than expected, due to how gecko handles scroll offsets.
If a display list is received, then a scroll event occurs, and then
a new display list is sent, the local rects will contain different
coordinates, since the scroll offsets are baked into the local
rects rather than in the scroll / reference frames. This results
in primitives being interned with a different value, and cached
surfaces being incorrectly invalidated.
Since the way this works is non-trivial to change in Gecko, we need
to handle this in WR.
If we change primitive and clip keys and templates to store their
rectangles in a true local primitive space (where the origin is
always zero) then the interning will work as expected. To do this,
we'll store the origin of a primitive in the instance, and only
the size in the template.
A side benefit of this approach is that test cases like dl_mutate
will become much faster, since the only difference between the
thousands of rectangles is the origin. This will effectively
allow true instancing of primitives with common data.
This is the first step towards that - by removing reliance of the
primitive local rect from the primitive template code. The rest
will be done as a series of incremental patches.
This change is