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 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 -----------------------------------------------------------