WebRender fallback software path

How to get a software WR renderer that has comparable performance to non-WR

We only want to have two tiers: full WR and full software. We are willing to add lots of workarounds to WR for driver bugs. That way, WR will replace both the current top tier, i.e. Direct2D + LayerManagerMLGPU, and the mid tier, i.e. software painting + Direct3D11 compositor.

Scrolling performance BasicCompositor scrolling works by blitting a PaintedLayer to the screen surface. This touches most of the pixels on the screen and does not benefit much from partial compositing. There aren't really any situations where we want partial composition with software where we wouldn't want it with hardware.

WR can cache expensive items on the page, e.g. individual radial gradients or blur filters.

One of the big things that webrender doesn't have that FrameLayerBuilder has is a way of mapping items to items from previous frames. That's what lets it do invalidation. Do we need this?

If we can make partial repaints as fast as BasicCompositor scrolling, that's good enough. There's no reason to have e.g. text selection be faster than scrolling of the root scroll frame.

Other browsers paint a lot of the screen in particular situations and seem to be ok. We can probably let ourselves be as bad as they are.

We can think of cases where it's hard to match the performance of the current software compositing. We don't have to meet the bar of the current implementation in all those cases, as long as we're somewhere as good as Chrome.

WR can still group multiple items into a cached intermediate surface. It can use a very naive grouping strategy. If the cached content is wrong due to OMTA or APZ scrolling, the incorrect parts can be redrawn. Example:

• You could have a transparent fixed element that overlaps your root scroll frame. You can draw everything into a cached layer for the scrolled contents, including the fixed layer.
• Then, after scrolling, you detect that the fixed element is now in the wrong spot. You can redraw that wrong area synchronously before you put things on the screen. This is not the smartest example, but it explains how the grouping doesn't necessarily have to anticipate asynchronous changes.

Two situations:

1. Scrolling
   • This isn't too hard to deal with because we know what's going on in the page. We can for example, tile and only paint the new tiles
2. New display list
   • This is hard. We don't know what to do.
   • Glenn doesn't think that this is that hard - you can just hash things.
   • i.e. you have a per tile list of intersecting display items that you hash. If the hash for that tile is different you redraw the tile.