[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 2: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
This is intentional. It does make for some inconsistent behavior between the implementation and between graphics drivers. But it is this way to allow implementations to be optimal, which differs according to graphics drivers.
> 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?
We did discuss and decided it would be a mistake to get the state involved at all, because we can't obey, for instance, the color mask since we must clear the buffers to a known state.
> I also don't quite understand this part
> By setting the preserveDrawingBuffer attribute of the WebGLContextAttributes object to true, the contents of the drawing buffer can be preserved until the author either clears or overwrites them. If this flag is false attempting to perform operations using this context as a source image after the rendering function has returned can lead to undefined behavior. This includes readPixels or toDataURL calls, or using this context as the source image of another context's texImage2D or drawImage call.
> That seems counter intuitive. The browser has the pixels. It has to be able to display them. Why do these functions have to have undefined behavior?
If the browser were making the decision what to do when then you're right, it can get access to the pixels. But these calls are author controlled, so the pixels just might not be available when they are requested. The reason for doing all this is just for hardware that asynchronously composites drawing buffers. Once you hand it to the compositing system, those bits are no longer available to the author or the browser.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: