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

Re: [Public WebGL] Ambiguity and Non-deterministicness in the WebGL Spec

On Dec 12, 2010, at 9:27 PM, Steve Baker wrote:

> On 12/12/2010 04:20 PM, Gregg Tavares (wrk) wrote:
>> The spec has changed to effectively require a clear each time the
>> WebGL draw buffer is composited
>>    WebGL presents its drawing buffer to the HTML page compositor
>>    immediately before a compositing operation, but only if the
>>    drawing buffer has been modified since the last compositing
>>    operation. Before the drawing buffer is presented for compositing
>>    the implementation shall ensure that all rendering operations have
>>    been flushed to the drawing buffer. By default, after compositing
>>    the contents of the drawing buffer shall be cleared to their
>>    default values. This includes the color buffer as well as the
>>    depth and stencil buffers if they are defined
>> As currently speced though, JavaScript has no way of knowing when the
>> drawing buffer will be composited and therefore when the buffer will
>> be cleared. For example, if a tab is hidden there may be no
>> compositing operation. If a JavaScript program is assuming WebGL will
>> clear the buffer for it each time it returns control the browser it
>> may be wrong.
>> Should the spec be changed to require a clear each time JavaScript
>> passes control back to the browser rather than the arbitrary only when
>> composited?
>> Also, the spec says they will be cleared to the default values. I
>> thought there was some discussion about clearing them to whatever the
>> current clear settings are. Was there some reason that was dropped?
> But what about honoring things like the ColorMask, DepthMask and Scissor
> settings?  Those things limit the ability of the clear screen function
> to reset every pixel to a known state.
> If you honor their settings, then the application can easily get around
> whatever thing you're trying to make happen by effectively shutting off
> write access to the frame buffer - so I suppose you'd have to save,
> force & restore those kinds of things each time.

Note that I don't say that the buffers are cleared to the current clear values in the state. This was intentional to make it clear that the state is not involved in this clear operation. But this clear operation can be done lazily. If the author first clears the buffers first (which will almost always be the case), then this clear can be skipped. Using the word "default" is really only a placeholder. We need to make it clear that it is the default value from the state, which I believe is well defined in the GLES spec.


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: