Do clipping and culling in raster space instead of the root world space
Categories
(Core :: Graphics: WebRender, task, P3)
Tracking
()
People
(Reporter: nical, Assigned: nical)
References
(Blocks 1 open bug)
Details
(Keywords: leave-open)
Attachments
(8 files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
We currently project everything into the root (world) space for clipping and culling calculations. This has a few drawbacks:
- We cannot compute clipping/culling and render content that cannot be projected to the root coordinate system. That's generally fine for content that isn't cached since the impossibility to project it means it can't be visible this frame, however it prevents us from making snapshots of stacking contexts that may become visible later if their transform changes.
- It assumes that we only do invalidation and caching on content that is in the root coordinate system. If we want to support caching arbitrary pictures with dirty rects, then these dirty rects must take into account the dirty region of at least the closest parent which also supports caching with dirty rects, instead of projecting the root dirty region. That is because the root dirty region projected into picture space and then projected into the parent's coordinate space may not cover the parent's dirty region entirely, leaving unaccounted invalid content (which may not be visible this frame, but will be if the cached content moves).
To address this, the plan is to move most or all of the world-space (root) computation into the space of the surface (raster space). With the caveat that in some places WebRender incorrectly labels "world space" coordinates that are in fact already in raster space.
Steps:
- Avoid using
global_screen_world_rect
, replace with a rect in the parent surface's space (raster space). - Express dirty rects into raster space instead of world space.
- Convert the clipping and culling code from world space to raster space. This is unfortunately the majority of the work and it is unclear how to split it into incremental steps.
Assignee | ||
Comment 1•24 days ago
|
||
This patch adds a temporary coordinate space which will as a first step be
synonymous to world space, but will eventually become raster space. This is
Done to facilitate identifying what parts of the world-space computations
need to move into raster space.
Assignee | ||
Comment 2•24 days ago
|
||
Depends on D238722
Assignee | ||
Comment 3•24 days ago
|
||
Depends on D238723
Assignee | ||
Comment 4•24 days ago
|
||
Depends on D238724
Assignee | ||
Comment 5•24 days ago
|
||
Depends on D238725
Assignee | ||
Comment 6•24 days ago
|
||
Depends on D238726
Assignee | ||
Comment 7•24 days ago
|
||
The commit is fairly mechanical except for one important thing: it assumes that
SpatialTree::get_root_transform is equivalent to SpatialTree::get_relative_transform
using the root node passed as the parent index parameter.
Depends on D238727
Assignee | ||
Comment 8•24 days ago
|
||
Depends on D238728
Assignee | ||
Updated•23 days ago
|
Comment 10•22 days ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/67c27aea8baf
https://hg.mozilla.org/mozilla-central/rev/3e4cc6dbff04
https://hg.mozilla.org/mozilla-central/rev/84eaf265da5b
https://hg.mozilla.org/mozilla-central/rev/f46a34e76fdc
https://hg.mozilla.org/mozilla-central/rev/f1ae18d41e50
https://hg.mozilla.org/mozilla-central/rev/ea0e7dd81e62
https://hg.mozilla.org/mozilla-central/rev/a215262dcfb1
https://hg.mozilla.org/mozilla-central/rev/3b75af5c5af7
Description
•