Compute the screen-space invalid rect and scissor out the rest when possible. (partial-present)

[nical]

I am being told that Gecko already does this on Windows (and that not doing it on Linux tends to cause a lot of wasted memory bandwidth).
Gecko is good at tracking invalidation, and that information is propagated all the way to the compositor, which can skip rendering anything outside of the damaged area with some cooperation from the window manager.
Can we (cheaply) generate this information in WebRender?

[kvark]

What kind of "cooperation from the window manager" do you have in mind?
It's not obvious to me that we can rely on the front buffer to have the old frame. For one, there is a swap chain of N buffers, which may be implementation dependent. Secondly, part of the window may be occluded.

[nical]

Looking at our CompositorD3D11 code, DXGI exposes ways to expose dirty rects in its DXGI_PRESENT_PARAMETERS struct. It doesn't look like DXGI gives you any information about the framebuffer it popped off the swap chain for that frame so I am assuming that the window manager is responsible for applying the damaged region of the window on top of what it had before. The doc only says that "The operating system uses this information to optimize presentation".

On Linux there is a different mechanism where the windowing system exposes the details of the swap chain through EGL's buffer age extension, and you are responsible for tracking which region is invalid for each texture of the swap chain. I sure GLX has a mechanism for that as well and since apple was the first to go nuts with pixel density, I would be surprised if Mac doesn't have something along these lines too.

Whether part of the window is occluded is independent of these mechanisms (if the windowing system has optimizations for this they are provided through other means).

[nical]

Actually the part I pointed to on the CompositorD3D11 might be something slightly different, but If you look at the same function we do set the clip rect of the d3d11 compositor to the invalid region for this frame, I'll look into why this works tomorrow.

[nical]

So here is how it works on windows specifically with DXGI: Gecko sets the DXGI_SWAP_CHAIN_DESC to use DXGI_SWAP_EFFECT_SEQUENTIAL. In this mode, DXGI blits only the dirty rects specified in the present parameters (from my earlier comment) of the content rendererd in the swap chain into the window's backing texture. This means that when the only thing that is moving is a spinning throbber or a blinking caret, we scissor out everything else in the page and only render that part.
We disable this on nvidia hardware due to bug 1189940.

[nical]

I'm looking at Chromium's code. It looks like they do the same thing (DXGI_SWAP_EFFECT_SEQUENTIAL with dirty rect in the present parameters), although they only maintain one damaged rect rather than a list of damaged rects as Gecko does. It's buried deep into layers of abstractions in ANGLE and I haven't found exactly where it connects to the compositor code yet. The way it seems to be exposed outside of ANGLE is through EGL's PostSubBuffer (extension) API, so that's probably what we would be using if we end up with WebRender on top of ANGLE.

[nical]

@glennw @mrobinson This is a pretty important optimization in Gecko (and Blink), do you think we can compute the screen-space damaged rect/region in WebRender or should we hook up invalidation information from Gecko?

[glennw]

It should be trivial to extract this from WR - most of the information is already present.

[gw3583]

We now support dirty rects and scissor the rest out with picture caching enabled.

[nical]

We don't do partial presents though, do we?