[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Ambiguity and Non-deterministicness in the WebGL Spec
On Dec 12, 2010, at 6:53 PM, Mark Callow wrote:
> On 13/12/2010 07:20, Gregg Tavares (wrk) wrote:
>> 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
> 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.
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 firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: