27513 2014-12-04 10:44:52 +0000 Clarify the behavior of Window.createImageBitmap(HTMLCanvasElement) for WebGL 2014-12-11 07:30:34 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified PC Linux RESOLVED WONTFIX P2 normal --- 1 dongseong.hwang dave.null junov kbr mike public-html-admin public-html-wg-issue-tracking public-html-bugzilla oldest_to_newest 115914 0 dongseong.hwang 2014-12-04 10:44:52 +0000 http://www.w3.org/html/wg/drafts/html/master/webappapis.html#cropped-to-the-source-rectangle "Let the ImageBitmap object's bitmap data be a copy of the canvas element's bitmap data, cropped to the source rectangle. " Above description is ambiguous for WebGL. WebGL has two kind of buffers; drawing buffer (i.e. back buffer) and presented buffer (i.e. front buffer) The spec should specifies which buffer should be copied to ImageBitmap. In my opinion, it should be presented buffer, because 1. the spec intends to copy the screenshot of webgl currently displayed. 2. drawing buffer is discarded in the next frame, so it's difficult to use this API to get RIGHT image. WDYT? 115963 1 kbr 2014-12-05 03:00:51 +0000 Thanks for pointing this out. I think this behavior probably needs to be defined in the WebGL spec, because otherwise the canvas spec will have to be modified to incorporate WebGL-specific concepts. I think the behavior should be: - If any rendering commands have been issued to the WebGL context since the last time its results were presented to the page compositor, the ImageBitmap should read the context's current contents (the "back buffer"). - Otherwise, the ImageBitmap should read the canvas's current contents (the "front buffer"). This will have less surprising behavior to developers that do the following: 1. Draw some WebGL to a canvas 2. Turn that canvas into an ImageBitmap 3. When the ImageBitmap is resolved, draw it to a different canvas's 2D context The intent here would be to have the ImageBitmap contain the rendering results from (1), but if the ImageBitmap always reads the canvas's "front buffer" then it'll contain whatever the canvas was displaying before step (1). 115974 2 kbr 2014-12-05 20:24:48 +0000 Sorry, I didn't think this through clearly. Per Dongseong's comments on https://codereview.chromium.org/776293002/ , the 'preserveDrawingBuffer=false' context creation attribute already defines this behavior when drawing a WebGL-rendered canvas to a 2D canvas context via drawImage, and ImageBitmap shouldn't behave any differently. 116003 3 dongseong.hwang 2014-12-08 07:47:20 +0000 @kbr, thank you for explaining. WebGL spec defines how readPixels, toDataURL, texImage2D and drawImage work. We made consensus that ImageBitmap should behave like them. It means ImageBitmap should copy the drawing buffer (i.e. back buffer). It might be good for WebGL spec to mention ImageBitmap in below sentence. https://www.khronos.org/registry/webgl/specs/latest/1.0/ """ This default behavior can be changed by setting the preserveDrawingBuffer attribute of the WebGLContextAttributes object. If this flag is true, the contents of the drawing buffer shall 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. """ 116136 4 kbr 2014-12-11 07:30:34 +0000 Thanks for the suggestion. The WebGL spec has been revised in https://github.com/KhronosGroup/WebGL/pull/805 . Closing this bug.