On Nov 15, 2010, at 6:19 PM, Kenneth Russell wrote:
> On Mon, Nov 15, 2010 at 5:37 PM, Chris Marrin <cmarrin@apple.com> 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.
That's surprising. If you're not double buffering now, it means that compositing and executing JavaScript (to do WebGL rendering to the drawing buffer) is happening on the same thread, or on threads that have to wait for each other to complete. Doesn't your compositing happen in a separate process? It seems like that would require you to have 2 separate drawing buffers.
>
> 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().
Right, but that was before the issue of how buffering works on iOS (and presumably other mobile hardware) came up. The reason for reconsidering explicit Present() now is because it gives authors control of the exact moment the drawing buffer is submitted for rendering and is no longer available for readPixel(), using it as an image source in another context's drawImage() or texImage2D, or toDataURL(). It is merely a side benefit that this allows authors to accumulate rendering over several JavaScript calls.
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.
-----
~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: