This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27513 - Clarify the behavior of Window.createImageBitmap(HTMLCanvasElement) for WebGL
Summary: Clarify the behavior of Window.createImageBitmap(HTMLCanvasElement) for WebGL
Status: RESOLVED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 normal
Target Milestone: ---
Assignee: This bug has no owner yet - up for the taking
QA Contact: HTML WG Bugzilla archive list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-04 10:44 UTC by Dongseong Hwang
Modified: 2014-12-11 07:30 UTC (History)
5 users (show)

See Also:


Attachments

Description Dongseong Hwang 2014-12-04 10:44:52 UTC
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?
Comment 1 Kenneth Russell 2014-12-05 03:00:51 UTC
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).
Comment 2 Kenneth Russell 2014-12-05 20:24:48 UTC
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.
Comment 3 Dongseong Hwang 2014-12-08 07:47:20 UTC
@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.
"""
Comment 4 Kenneth Russell 2014-12-11 07:30:34 UTC
Thanks for the suggestion. The WebGL spec has been revised in https://github.com/KhronosGroup/WebGL/pull/805 . Closing this bug.