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

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

----- Original Message -----
> 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?

It would add an extra buffer to ours at least, and would complicate the implementation even more if we're using pbuffers instead of FBOs.

Somewhat off the wall idea... What if we added some form of snapshot API which would have the current contents of the canvas be saved as a snapshot which would be handed to drawImage, texImage2D, etc?  Otherwise they'd get transparent black.  Then we'd keep the implicit present with an implicit clear/invalidation after each present, but allow for web content to say "I just drew something that I'd like to later use in drawImage or texImage2D".  That snapshot could be implemented lazily, so that if you draw something to a webgl canvas, call snapshot(), call drawImage with it as a source, and call something like releaseSnapshot(), no extra buffer would need to be created.  So, something like:

  snapshot() -- the current contents of the drawing buffer are saved, any use of this canvas as a source for 2d canvas drawImage or 3d canvas texImage2D (and maybe printing?) will result in the saved snapshot being used instead.

  releaseSnapshot() -- any current snapshot is released, and using this canvas as a source will result in transparent black.

This makes this operation very explicit, and potentially allows for interesting use cases (e.g. taking a snapshot, and calling texImage2D with your own canvas as the source, from a few frames back?).

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

You mean never seen by itself, right?  Because draw #2 would happen on top of the clear/drawElements, since "true" was passed to Present.

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