[Public WebGL] Updating the Spec W.R.T. preserveDrawingBuffer = false

Gregg Tavares [email protected]
Mon Jun 10 23:05:30 PDT 2013


Let's try that again. Hopefully the browser won't send my email.

---

I don't think we have the luxury to break existing apps which is why I
suggested that using the canvas as a source only uses the buffer being
composited until a draw call is made.

That way code like this

function capture() {
   var img = new Image();
   img.src = gl.canvas.toDataURL();
   document.body.appendChild(img);
}

gl.drawXXX(); // draw stuff
capture();
gl.drawXXX(); // draw more stuff
capture();
gl.drawXXX(); // draw yet more stuff
capture();


continues to work. Code like this is in the conformance tests.

If you had this

       function render() {

capture();
gl.drawXXX(); // draw stuff
capture();
gl.drawXXX(); // draw more stuff
capture();
gl.drawXXX(); // draw yet more stuff
capture();

      }
      requestAnimationFrame(render);

Under the current spec that first call to capture makes a blank image.
Under the proposed changes you get the last frame. That's the only change
I'm suggesting.  I'm making the assumption that no one is capturing blank
frames on purpose.

As I said, it makes no sense to me that I can print the canvas, I can move
the canvas in the DOM, I can apply CSS animations and effects to the canvas
but I can't get it's content. The content exists. It seems like I should be
able to get it one way or another.

Under the DrawingBuffers proposal most of this goes away. You can pass a
DrawingBuffer to texImage2D or call DrawingBuffer.toDataURL, and what you
get is 100% clear. readPixels and copyTexImage2D are also 100% clear in
both cases. They are always the DrawingBuffer that is current on the
context.

It's only the canvas case that needs clarification and that's because it
has this buffer copy/swap stuff going on behind the scenes.



















On Mon, Jun 10, 2013 at 10:53 PM, Gregg Tavares <[email protected]> wrote:

> I don't think we have the luxury to break existing apps which is why I
> suggested that using the canvas as a source only uses the buffer being
> composited until a draw call is made.
>
> That way code like this
>
>
>
>    // progressively capture as I draw
>    gl.drawXXX();  // draw stuff
>    gl.drawXXX();  // draw more stuff
>    (new Image()).src = gl.canvas.toDataURL();
>    gl.drawXXX();  // draw more stuff
>    (new Image()).src = gl.canvas.toDataURL();
>
>
>
>
>
> On Mon, Jun 10, 2013 at 10:30 PM, Mark Callow <[email protected]>wrote:
>
>>  On 2013/06/11 9:28, Kenneth Russell wrote:
>>
>> This proposed preserveDrawingBuffer change probably would not decrease
>> WebGL's efficiency in the majority of browsers and on the majority of
>> OSs. The browser can still use DiscardFramebufferEXT for the depth and
>> stencil buffers when presenting the WebGL canvas to the compositor. In
>> my understanding, it's never been possible to discard the color
>> buffer, because the page compositor needs it in case the page needs to
>> be redrawn using the same WebGL results from the previous frame. Since
>> the color buffer is always available after compositing, it can be made
>> available to toDataURL and other APIs at no cost.
>>
>>  I think you are slightly misunderstanding both preserveDrawingBuffer and
>> DiscardFramebufferEXT.
>>
>> IIUC, all browsers render into framebuffer objects. They use the
>> resulting framebuffer for compositing with the rest of the web page. The
>> browser must either
>>
>>    1. maintain 2 or more buffers, one for drawing and one for
>>    compositing, or
>>     2. ensure that the WebGL application's draw functions are not called
>>    until the buffer is no longer needed by the compositor.
>>
>> In the former case pDB=true requires copying the data from the buffer
>> received for compositing to the next one handed to the WebGL application to
>> draw into. In the latter case the value of pDB is immaterial. Data is
>> preserved.
>>
>> The purpose of DiscardFramebufferEXT is to tell a tiling GPU that is does
>> not need to copy the data corresponding to the current tile from the
>> framebuffer of the previous frame into the tile memory prior to rendering.
>> *It has no effect whatsoever on the content of a framebuffer*.
>> Copy-to-tile only needs to be done when pDB==true. When pDB==false, the
>> browser can always call DFExt before calling the WebGL app's draw function.
>>
>> I suspect most browsers use the multiple buffer model. So it seems
>> sensible to define that toDataURL and drawImage receive the data from the
>> current compositing buffer rather than the current drawing buffer whose
>> content is likely still a work in progress. It makes sense for the
>> tex*Image2D calls too. The proposed change means that tex*Image2D(...,
>> canvas), where canvas is the current canvas, would actually capture the
>> content of the previous frame. I think this is okay. If the app wants to
>> capture the content of the current drawing buffer, it can use copyTexImage
>> which is much more efficient anyway.
>>
>> Regards
>>
>>     -Mark
>> --
>>  注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、
>> 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.
>>
>> NOTE: This electronic mail message may contain confidential and
>> privileged information from HI Corporation. If you are not the intended
>> recipient, any disclosure, photocopying, distribution or use of the
>> contents of the received information is prohibited. If you have received
>> this e-mail in error, please notify the sender immediately and permanently
>> delete this message and all related copies.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20130610/ce5580ae/attachment.html>


More information about the public_webgl mailing list