On Mon, Dec 13, 2010 at 11:02 AM, Chris Marrin <email@example.com>
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.
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
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.
> 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?
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.
> 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?
I'm not sure what you mean by "those bits are no longer available to the author or the browser." The compositor has to keep copies of the bits until new bits are supplied which may be never. So the bits are always available. The user might scroll, the author might change the visibility of the canvas or its style size, all of which will require it to get re-composited but does not require WebGL to re-render. So there are always bits around.
It seems anti-HTML for there to be a canvas on the page that I is being displayed, can be moved, resized, hidden, etc and yet I can't call toDataURL, drawImage or texImage2D using that canvas.