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

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



On Nov 18, 2010, at 11:38 AM, Vladimir Vukicevic wrote:

> 
> There's a pile of pros and cons for almost any set of choices here :-)  Here's what we've come up with:
> 
> - Anything that will read from the color buffer (readPixels, drawImage, etc.) is fair game before a present happens.  It will return the correct results for current rendering.
> 
> - Present will continue to happen implicitly as it does today.
> 
> - A context attribute will be added, provisionally called preserveDrawbuffers, which will default to false.

I think to match our use of "drawing buffer" in the prose of the spec, the attribute should be called 'preserveDrawingBuffer'.

> 
> - When a present occurs:
>  - if preserveDrawbuffers is FALSE: the color/stencil/depth buffers are set to the default values.
>  - if preserveDrawbuffers is TRUE: the color/stencil/depth are untouched.
> 
> - If a canvas/webgl context is used in a way that its contents are not directly displayed to the screen, then no present ever occurs.  For example, creating an offscreen canvas which is then used as a source for drawImage only without being attached to the displayed DOM.

One other minor clarification we should make is that if such an offscreen HTMLCanvasElement is added to the DOM tree, an implicit Present will occur some time after that and all the above rule will apply.

> 
> 
> Applications can continue to use readPixels, drawImage, etc. normally, as long as they coordinate with the webgl drawing and do it in the same JS execution period as their WebGL drawing.  If they need to arbitrarily do drawImage/etc., then they can set the preserve flag and be able to do so.  We considered an explicit present, but there are many complexities with that approach that implicit was simplest, without obviously making any use cases impossible.

It should also be noted that there is ambiguity in the wording which makes it possible for applications to behave differently on different hardware. For instance, when some JS function (e.g., an event handler) is called after the JS WebGL rendering function returns, the drawing buffer may or may not be cleared when preserveDrawingBuffers is false. This is because implementations call Present at different times. We discussed tightening up the semantics but decided against it to give implementations the most opportunity to optimize.

One other note. The semantics described can cause existing content to behave differently than before. Content that relied on the drawing buffer being preserved will break. But we agreed that the amount of content broken would be small and making the default value of preserveDrawingBuffer false makes it possible for more implementations to be fully optimized.

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