[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] preserveDrawingBuffer questions

On Tue, Oct 4, 2011 at 4:19 PM, Benoit Jacob <bjacob@mozilla.com> wrote:
> Hi,
> Section 2.2 has a non-normative block saying "While it is sometimes
> desirable to preserve the drawing buffer, it can cause significant
> performance loss on some platforms." Could someone please point me to the
> corresponding discussion, which I can't find back? What were these platforms
> and why is that slow on them?

Mobile devices in particular can benefit from this, especially if
they're already using a compositor to get GL content to the screen.
In that case, you hand off a buffer/texture to be drawn to the screen,
and if preserve=true, then you would need to make a copy of it before
doing so in order to keep drawing on top of the same scene.

> Another question: implementing the default semantics
> (preserveDrawingBuffer=false) on a multi-process browser seems tricky to do
> efficiently: as far as I can see, this requires double buffering?

A multiprocess implementation is actually precisely when
preserve=false can provide a speedup.  You have to double buffer no
matter what -- when you're ready to composite, if you're multiprocess,
you have to hand off buffer A for drawing to the screen while you draw
into buffer B.  If preserve=false, you just swap A and B, clear B, and
draw into it while A is being composited.  If preserve=true, you have
to copy A->B before handing off A and moving drawing to B.

     - Vlad

You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl