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

Gregg Tavares [email protected]
Mon Jun 10 22:53:16 PDT 2013

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/ed6511cb/attachment.html>

More information about the public_webgl mailing list