1548396 - Support picture caching on child pictures.

Status: NEW

(Core :: Graphics: WebRender, enhancement, P2)

Description

[Glenn Watson [:gw]]

In some cases (e.g. constantly changing content with animated 3d transforms) we need to redraw the main scene each frame. In this case, normal picture caching is of no benefit, but we can still benefit in some cases by caching the output of child pictures (such as mix-blend-mode nodes).

This will be much simpler to implement as a follow up to the ongoing picture caching improvements.

Comment 1

[Nicolas Silva [:nical]]

Glenn, could you write down what you have in mind about tracking non-root picture dependencies?

Comment 2

[Glenn Watson [:gw]]

There's two bits of work I can think of that we need to do for this task (there might be others that become apparent once we dig into it).

1. We need to store dependencies on each picture, rather than storing them all on the top-level picture that represents the cache slice.

This is fairly trivial for pictures that only have a single tile. In that case, we simply store the tile dependency on each picture, and when a child picture gets invalidated the entire parent picture also gets invalidated. However, we want to support both the parent and child pictures being tiled, to reduce the size of the invalidated area.

The basic idea for this that we discussed at the last all-hands is to have a special code path when considering primitive dependency for picture primitives that knows how to invalidate parts of a picture only, based on the dirty state of the child picture tiles. I think this is relatively simple, but I'm not certain until we actually start the implementation. I think it's possible we can also leverage the recent dirty rects work to make this quite efficient and a fairly small code change.

2. Increase our use of rasterization roots and implement local-scale support to enable this.

We will want to draw any child pictures that are being cached in local space, rather than screen-space for two reasons (a) the picture caching code relies on axis-aligned rectangles for a lot of the tiling logic, which is difficult or impossible to get perfect when rasterizing in screen-space and (b) There's little point in caching in screen-space when a child picture is being animated since it would change every frame - we want to rasterize in local space, cache the output and apply the final transform when drawing into the parent picture.

We have rasterization root support that we use in production for elements with perspective. In theory, we just need to add a line of code that marks cached child pictures as establishing a rasterization root. However, there are a couple caveats:

(a) Rasterization roots are only used for perspective transforms, which are quite rare, so there might be bugs or test issues to fix when using them more widely.
(b) We only support local-space rasterization with 1:1 scale with the supplied coordinates. This means that for extremely large elements, we have to disable the rasterization root (surface would be too large) or for elements with large final scale transforms, we would rasterize them at a resolution where visual artifacts are apparent due to the low surface resolution. We need to add support for rasterizing in local space with a given scale factor - this is not super difficult, it's just work.

Hope that helps!

Comment 3

[Glenn Watson [:gw]]

Un-assigning for now, until I have time to work on this.

Comment 4

[Nicolas Silva [:nical]]

I am hoping that this will help with most of the issues in the "Too many render targets" list here: https://github.com/servo/webrender/wiki/Performance-triage#too-many-render-targets