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

Re: [Public WebGL] double-buffering and back buffer preservation



On Nov 15, 2010, at 5:23 PM, Vladimir Vukicevic wrote:

> 
> Adding a Present function seems like it certainly has advantages. Why not require it instead of having the current behavior? Like others have mentioned, this makes it more like real OpenGL and makes it easy to spread out rendering across callbacks, possibly making it better for web worker stuff in the future as well.
> It has a cost -- it would mean that you would have to double-buffer all webgl content; that is, you'd have to be able to keep the displayed front buffer entirely separate than the back buffer.  Right now, a WebGL implementation can have a single buffer (for example, a FBO) that it can both render to and use as a texture for compositing.

Damn, you're right. I think I'm seeing how we arrived at the "explicitPresent" flag in our last go-round with this. I really like the idea of explicit Present() because it takes away the question of when Present() is performed. As I said in my last response to Gregg, leaving that open makes it a question of when you can and when you can't use the contents of the drawing buffer as an image source.

In the current WebKit implementation we are already double buffered just because of the way it is implemented. and our (future) iOS implementation is double buffered because of the way the hardware works. Does the "double-buffered" requirement add overhead to any of the other implementations? If not, maybe explicit Present() is reasonable?

> 
> Chris, if I'm understanding your proposal correctly, a code snippet like this:
> 
> function draw(gl) {
>   gl.clear(..);
>   gl.drawElements(..); // draw #1
>   gl.Present(true);
> 
>   gl.drawElements(..); // draw #2
> }
> 
> would have an implicit Present(false) at the end, with the displayed buffer containing draw #2 on top of draw #1, and the next time GL drawing happens (that is, the current conceptual back buffer) being cleared/invalid?

Right, in the above case, the rendering that occured in draw #1 would never be seen.

-----
~Chris
cmarrin@apple.com




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