>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 g
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.
Experiments and calculations show that the previous SOC we had for Flatfish
(tablet) could only fill about 3x the frame buffer size at 60fps. Without
culling occluded layers the homescreen would only pan at 25 FPS or so. So
yes, this is very much motivated by concrete hardware problems. Tablets
ten
2013/8/31 Andreas Gal
>
> 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
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 res
5 matches
Mail list logo
