[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Ambiguity and Non-deterministicness in the WebGL Spec
On 2010-12-13 20:08, Chris Marrin wrote:
The problem with saying it is undefined is that it will essentially mean
you have to do whatever most desktop versions are doing or the content
will not work. My guess is that most desktop versions would in this case
do a copy of the buffer to avoid all the issues with doDataURL,
readPixels etc. In that case the spec says you can do whatever you want,
but in order to be compatible with the content you have to reverse
engineer what other implementations are doing and do the exact same
thing. For that reason I think leaving it undefined would be a mistake.
On Dec 12, 2010, at 6:53 PM, Mark Callow wrote:
On 13/12/2010 07:20, Gregg Tavares (wrk) wrote:
Please remind me why this clearing is necessary. If it is for "security" then surely this extra clearing is only necessary if the drawingBuffer is given to a different webgl context that original drew the contents.
The spec has changed to effectively require a clear each time the WebGL draw buffer is composited
... By default, after compositing the contents of the drawing buffer shall be cleared to their default values. This includes the color buffer as well as the depth and stencil buffers if they are defined
In the case of iOS, when you commit a drawing buffer, you're handed another new one. This could be a buffer you had before or one that is totally new and has leftover pixels from another process. And as I've mentioned, in the common case this clear operation can be skipped.
As I pointed out in a previous e-mail not all applications use glClear() because their other rendering will fill the entire buffer. In those cases following the above is overhead that cannot be optimized away. When I was at SGI, we used to go to enormous lengths to make sure the clear operation was fast because it has an enormous effect on the overall frame-rate. It feels really painful to be introducing extra clears.
Yes, that is a case that can't be easily optimized away. I think we need to live with that for now. We could always say that the drawing buffers have values that are "undefined but guaranteed to contain information from another process", or something like that. That would mean many desktop implementations would never have to do it since they are swapping between 2 buffers. The case that would be most expensive is on iOS (or similar mobile implementations) when the author does not do a Clear. I can live with that for this release.
You are currently subscribed to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: