Mitigate very large snapshots using an optional clip
Categories
(Core :: CSS Parsing and Computation, task)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox144 | --- | fixed |
People
(Reporter: nical, Assigned: nical)
References
(Blocks 1 open bug)
Details
(Whiteboard: [viewtransitions:m2:gfx])
Attachments
(2 files)
Right now, WebRender is limited in the amount of physical pixels that can be allocated per snapshot to a single (4kx4k) texture. Larger snapshots are rasterized at a lower resolution and show up blurry.
I think that we can work around a lot of the worst cases by restricting snapshots to a conservative area around the visible portion of the snapshot it it is too large.
It could be done via an extra clip in the display list, or a visible area could be passed to WR as part of the snapshot params in the stacking context so that webrender generates the clip during scene building. Either way I think that WebRender's scene builder does not have the appropriate information about the stacking context's visible area so we'll need at least that information from displaylist building.
The extra clip would be based on the estimated (or precise if we have that) visible rect of the snapshot and ideally an estimate of the resolution at which the snapshot is rendered.
It could use simple rules like:
- if the snapshot fit within 4k x 4k rasterized pixels, do nothing
- if the snapshot is entirely invisible at the end of the transition, do nothing (it will be blurry)
- otherwise, clip the snapshot against an arbitrary rect based on the visible portion of the snapshot.
- The clip would include the visible portion of the stacking context, inflated in the directions that don't fit in the visible area until the maximum size is reached (currently 4k x 4k physical pixels).
With this type of mitigation we would trade some blurriness with an equivalent of checkerboarding. For the completely off-screen case where there is no visible portion of the stacking context to hint at the best place to clip, we could try something fancy, for example taking the closest 4kx4k area of the snapshot to the global viewport. If the snapshot is going to animate into view it is likely from that side. But I suspect that this case will be rare enough in practice that we shouldn't need to do heroics for it.
Another note is that we can play on both resolution and clip. For example we can double the area of the clip if we accept some blurriness.
If it is difficult to estimate the resolution during display list building, we can start with a first approximation that 1 layout pixel = 1 physical pixel. This would defeat the heuristic when the element is inside a transform with a strong scaling factor, but it would cover the most common cases and should behave gracefully in this situation as long as the clip always include the visible portion of the snapshot at the beginning of the transition.
|
Assignee | |
Updated•1 year ago
|
|
|
Assignee | |
Updated•1 year ago
|
|
||
Updated•1 year ago
|
|
|
Assignee | |
Comment 1•1 year ago
|
||
This patch introduces a heuristic to determine whether a snapshot is large and if so, restrict it to the most suitable subset of the captured rect.
The idea is to compare the captured rect with the visual viewport. If the captured rect is larger than the viewport, then it is known to cover more than what is currently visible and likely to be very large. To avoid raserizing a very large snapshot and possibly having to do so at a low resolution, we use only a portion of the captured rect that is closest to the visual viewport and at most as large as the latter.
|
||
Updated•1 year ago
|
|
|
Assignee | |
Comment 2•1 year ago
|
||
Backed out for causing wr failures
|
|
Assignee | |
Updated•1 year ago
|
|
||
Comment 7•1 year ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/45f105fd07f7
https://hg.mozilla.org/mozilla-central/rev/01b0c7de2eb8
https://hg.mozilla.org/mozilla-central/rev/7aabf176e583
|
||
Updated•1 year ago
|
Description
•