We actually have code that does the computation of the dirty area
already, see
http://mxr.mozilla.org/mozilla-central/ident?i=LayerProperties&tree=mozilla-central.

The idea is that we take a snapshot of the layer tree before we update
it, and then do a comparison after we've finished updating it.

We're currently only using this for main-thread BasicLayers, but we're
almost certainly going to need to extend it to work on the compositor
side too for OMTC BasicLayers.

It shouldn't be too much work, we just need to make ThebesLayers shadow
their invalid region, and update some of the LayerProperties comparison
code to understand the **LayerComposite way of doing things.

Once we have that, adding compositor specific implementations of
restricting composition to that area should be easy!

- Matt

On 1/09/13 4:50 AM, Andreas Gal wrote:
>
> Soon we will be using GL (and its Windows equivalent) on most
> platforms to implement a hardware accelerated compositor. We draw into
> a back buffer and with up to 60hz we perform a buffer swap to display
> the back buffer and make the front buffer the new back buffer (double
> buffering). As a result, we have to recomposite the entire window with
> up to 60hz, even if we are only animating a single pixel.
>
> On desktop, this is merely bad for battery life. On mobile, this can
> genuinely hit hardware limits and we won't hit 60 fps because we waste
> a lot of time recompositing pixels that don't change, sucking up
> memory bandwidth.
>
> Most platforms support some way to only update a partial rect of the
> frame buffer (AGL_SWAP_RECT on Mac, eglPostSubBufferNVfor Linux,
> setUpdateRect for Gonk/JB).
>
> I would like to add a protocol to layers to indicate that the layer
> has changed since the last composition (or not). I propose the
> following API:
>
> void ClearDamage(); // called by the compositor after the buffer swap
> void NotifyDamage(Rect); // called for every update to the layer, in
> window coordinate space (is that a good choice?)
>
> I am using Damage here to avoid overloading Invalidate. Bike shedding
> welcome. I would put these directly on Layer. When a color layer
> changes, we damage the whole layer. Thebes layers receive damage as
> the underlying buffer is updated.
>
> The compositor accumulates damage rects during composition and then
> does a buffer swap of that rect only, if supported by the driver.
>
> Damage rects could also be used to shrink the scissor rect when
> drawing the layer. I am not sure yet whether its easily doable to take
> advantage of this, but we can try as a follow-up patch.
>
> Feedback very welcome.
>
> Thanks,
>
> Andreas
>
> PS: Does anyone know how this works on Windows?
> _______________________________________________
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reply via email to