[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] double-buffering and back buffer preservation
On 16/11/2010 06:56, Vladimir Vukicevic wrote:
> ... Content can also read back the current contents of the displayed image (in 2D canvas, via getImageData; in WebGL, via readPixels; and in both via toDataURL).
In native GL ReadPixels returns data from the current write buffer which
in the case of "back buffered," i.e. window, surfaces is the back
buffer. It does not return content from the displayed image.
The WebGL spec. is unclear about this. In section 5.13.12, cribbing
language from the OpenGL ES 2.0 spec., it says it reads from the "frame
buffer". "Frame buffer" is undefined. In section 2.1 it says
"readPixels() may be used to obtain the contents of the drawing buffer.
Neither case says anything about the displayed image or the canvas.
By the way in section 4.2 it says "readPixels method of the 2D context".
I don't understand this. I thought you used getImageData for a 2D context.
So readPixels behaviour is unaffected by whatever decision is made about
posting of the drawing buffer.
> 2) Add explicit double-buffering to WebGL canvases, and add an explicit present() call. This complicates things for developers, because they need to then actually make this present() call, and can potentially result in higher memory usage due to some implementations needing to keep around both a front and back buffer, where before they could be effectively single-buffered.
I do not think it will change anything in terms of memory usage.
Implementations today are double buffered. They have a drawing buffer
and then the buffer for the displayed canvas - possibly part of a larger
buffer used for the whole page.
> 3) Add implicit double-buffering to canvas. Follow the same semantics as canvas does currently -- swap happens whenever control is returned to the browser -- but always enforce an uninitialized/cleared back buffer after each swap.
Enforcing a clear will cause all of the problems we are trying to avoid.
But realize that the contents seen in an "uninitialized" back buffer
will be parts of the frame before last. The only chance of seeing data
from another application would be prior to the application's second
frame being posted and the only way to read it, by getImageData() from
the currently displayed buffer.
org:HI Corporation;Graphics Lab, Research & Development
adr:Higashiyama 1-4-4, Meguro-ku;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan
tel;work:+81 3 3710 9367 x228
tel;fax:+81 3 5773 8660