1381981 - Add invalidation for blob image

Status: RESOLVED FIXED

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

Description

[Jeff Muizelaar [:jrmuizel]]

The plan here is to use a separate recording per display item, along with an index that gives the bounds of the display items.

With the index we can merge an update blob image with an existing blob image to produce a blob image that represents the update.

Comment 1

[Nicolas Silva [:nical]]

One thing to be careful about is that even though webrender supports specifying a dirty rect for image updates, it assumes that you can still re-render the whole thing in some situations (like if the image is not in the texture cache or if the size changed).
If you want to send a subset of the blob image recording that only renders the dirty rect, you will also need to make sure the blob image renderer is able to build the previous version of the image and replay the update on top of it.

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Yep, the intention is that we'll have a merged recording that can will support drawing the entire blob image.

Comment 3

[Jeff Muizelaar [:jrmuizel]]

The basic sketch for collecting the necessary information for this is as follows:
 - We add a FlushItem(rect) to DrawTarget.
 - Every time that FlushItem is called we start a new recording in DrawTargetRecording.
 - For items that use a temporary surface we'll we'll end up with a FlushItem for the PushLayer call and a FlushItem for the PopLayer call (or equivalent creating/painting of a source surface) 


FlushItem will need a device pixel bounding rect for every item that is being painted. It's not clear to me what the best way to get this is. Thoughts?

Comment 4

[Matt Woodrow (:mattwoodrow)]

FrameLayerBuilders DrawItems function knows the bounds of the items that it draws.

How do you plan on correlating each entry in the list back to the items?

Comment 5

[Matt Woodrow (:mattwoodrow)]

I guess you're building this on top of Layer free actually. Still the nsDisplayItem knows the bounds that will be painted, so you can use that.

Can we just create a new recording by hand, rather than adding a new API to DrawTarget?

FlushItem doesn't really make sense for any other consumer of Moz2D, so it seems a pain to add it to the general API.

Comment 6

[Jeff Muizelaar [:jrmuizel]]

So after trying to get this to work with FrameLayerBuilder's invalidation, I've concluded that it's probably more work to get working than is worth it. It's not easy to get a good bounding box per frame that corresponds to an area that's strictly inside the invalidation region.

i.e. ComputeGeometryChangeForItem does quite a bit of processing on bounds and such before passing this down to accumulate into a region. We'd need to replicate this when recording the bounds or maintain the information some other way. I've also needed other hacks (like disabling subframe invalidation) to make things work. At this point it seems easier to build up the invalidation infrastructure that we'll need to match, as we'll need to build it for layers-free anyways.

Comment 7

[Jeff Muizelaar [:jrmuizel]]

This is on now.