>From an API/feature point of view the partial buffer swap does not sound like a bad idea, especially since, as Mat said, the OMTC BasicLayers will need something along these lines to work efficiently. One thing to watch out for, though, is that it is the kind of fine tuning that, I suspect, will give very different results depending on the hardware. On tile based GPUs, doing this without well working extensions like QCOM_tiled_rendering will most likely yield bad performances, for example. More importantly I am not sure how much we can rely on these extensions reliably behaving across the different hardware. Would we use something like WebGL's blacklisting for this optimization? I heard that our WebGL blacklisting is a bit of a mess.
Are these the lowest hanging fruits to improve performances? On Sun, Sep 1, 2013 at 6:53 AM, Matt Woodrow <m...@mozilla.com> wrote: > 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 > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
