[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.drawXXX();  // draw more stuff
   (new Image()).src = "">

On Mon, Jun 10, 2013 at 10:30 PM, Mark Callow <callow.mark@artspark.co.jp> 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.



注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

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.