[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 11:24 PM, Vladimir Vukicevic wrote:

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

But that's just like my proposal of an optional  Present(true) function, right? If you don't call Present() explicitly, it gets called implicitly like today. If you don't call it or call Present(false) then the contents of the drawing buffer are not accessible. If you call Present(true), the contents of the drawing buffer are accessible until explicitly cleared or overdrawn by WebGL.

I am in favor of any proposal that, by default makes the drawing buffer inaccessible (implicitly cleared) after Present(), whether it's implicit or explicit. That makes the default case fast on mobile devices. 

Hmmm, now I'm not remembering why my proposal requires an additional drawing buffer. If you have a single buffered case today, it means you are rendering to the drawing buffer with WebGL via JavaScript in the same thread you are compositing that buffer with the rest of the page. So requiring that the drawing buffer be cleared after Present() should not incur the need for another buffer, should it? I looked back in the thread and didn't find where this was discussed. Was it at the F2F?

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