[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 6:19 PM, Kenneth Russell wrote:
> On Mon, Nov 15, 2010 at 5:37 PM, Chris Marrin <firstname.lastname@example.org> wrote:
>> 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?
> Perhaps in Safari on Mac OS X Core Animation already provides the
> necessary additional buffer, but adding an explicit present() would
> require the addition of another texture the size of the WebGL rendered
> canvas in the Chromium implementation.
> Applications can allocate FBOs if they want to build up rendering
> results over multiple render callbacks. For this reason the previous
> discussions in the WebGL working group rejected the addition of an
> explicit present().
As I think about this more, it seems that accommodating systems that make drawing buffers inaccessible after submission for compositing and making the moment when a buffer is submitted well defined far outweigh the cost of an additional drawing buffer in systems that don't already have them. We could add a context attribute to accommodate both systems. But that requires that authors use such a flag. What would the default be? Since systems that make drawing buffers inaccessible after a Present() are the ones where performance issues are the greatest, I think we have to make that the default. And I think we have to make support for that mode required. So systems that today don't have double buffering would have to add it. Then why would an author flip the flag? It would save a buffer allocation on some desktop systems, which in most cases would not really be noticeable. And it would be a huge impact on mobile systems, which would be very noticeable.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: