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

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



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 = "">
   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 <gman@google.com> 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.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.

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.