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

Re: [Public WebGL] preserveDrawingBuffer questions



What Vlad says is true, but the issue goes deeper than that. On a tiling GPU, which architecture is in the majority in the mobile/low-power space, if preserve=true the area of the previous frame's render-buffer corresponding to the tile being worked on has to be copied into the high-speed tile memory.

Regards

-Mark



On 2011/10/05 5:28, Vladimir Vukicevic wrote:
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
-----------------------------------------------------------