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

Mark Callow [email protected]
Mon Jun 10 22:30:38 PDT 2013


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/20130611/6c4b8e24/attachment.html>


More information about the public_webgl mailing list