Open Bug 1946457 Opened 1 month ago Updated 22 days ago

Do clipping and culling in raster space instead of the root world space

Categories

(Core :: Graphics: WebRender, task, P3)

task

Tracking

()

People

(Reporter: nical, Assigned: nical)

References

(Blocks 1 open bug)

Details

(Keywords: leave-open)

Attachments

(8 files)

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.

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.

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

Keywords: leave-open
Pushed by nsilva@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/67c27aea8baf Add VisRect. r=gw https://hg.mozilla.org/integration/autoland/rev/3e4cc6dbff04 Add a visibility_node_index parameter in TileCacheInstance. r=gw https://hg.mozilla.org/integration/autoland/rev/84eaf265da5b Change DirtyRegion to use VisRect instead of WorldRect. r=gw https://hg.mozilla.org/integration/autoland/rev/f46a34e76fdc Make add_split_plane work without assuming world space. r=gw https://hg.mozilla.org/integration/autoland/rev/f1ae18d41e50 Make compute_conservative_visible_rect work without assuming world space. r=gw https://hg.mozilla.org/integration/autoland/rev/ea0e7dd81e62 Store a culling rect and visibility node in SurfaceInfo. r=gw https://hg.mozilla.org/integration/autoland/rev/a215262dcfb1 Plumbing to pass the visibility spatial node to the clipping code. r=gw https://hg.mozilla.org/integration/autoland/rev/3b75af5c5af7 Move build_clip_chain_instance's world space usage to vis space. r=gw
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: