1666429 - Separate picture traversal and rendering primitive

Status: NEW

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

Description

[Nicolas Silva [:nical]]

The way we recurse over the tree of pictures today is nested like this:

 - set some state for the parent picture
 - process primitive A0
 - process primitive B0
 - process primitive C0 (it's a child picture)
     - set some state for the child picture
     - process child picture's primitive A1
     - process child picture's primitive B1
     - ...
 - resume working on parent picture
 - process primitive D0
 - ...

Instead I would like something like this:

 - parent picture:
     - child picture:
     - process primitive A1
     - process primitive A2
     - ...
 - process primitive A0
 - process primitive B0
 - process primitive C0
 - process primitive D0
 - ...

where we recurse over the child pictures before processing primitives.

A picture would contain:

• A list of child pictures (it's a tree structure)
• A list of low level rendering primitives, none of which is a picture primitive. Instead of picture primitives we would have one or several image or filter primitives that know where to find the content of the child pictures.

In the visibility pass we would compute the visibility of child pictures separately from the rendering primitives.
in later passes we can do a bottom up traversal so that child pictures are processed earlier than the rest of the primitives for a given surface.

Advantages:

• The current scheme forces us to duplicate rendering code and/or add arbitrary limitations depending on whether a primitive is or isn't a picture (for example we can't run a filter on an image, it has to be a picture which implies reading from the render task cache).
• There is value in being able to process the child-most primitives as early as possible, for example so that we can submit their drawing commands as early as possible.
• Traversing the rendering primitives in a simple loop without nesting the child picture recursion in the middle has a better chance of working well with the texture cache: primitives before and after a child picture are more likely to be in the same texture since we won't be inserting texture cache allocations in-between.
• The current nested traversal prevents us from efficiently reusing memory allocations during batching, which would be trivial to do once pictures are batched one after the other. These allocations are usually high in profiles.
• I think that the code would be simpler overal once we separate the complicated parts of handling pictures from the rendering primitives.
• Eventually we'll have a much easier time if we want to process pictures in parallel.

Comment 1

[Glenn Watson [:gw]]

I like the general concept.

There's likely to be a few ordering / dependency complexities (specific ones I can think of: allowed subpixel modes, raster root determination, filter bounds inflation), but if we can resolve those it sounds good.