[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 14, 2010, at 2:12 AM, Mark Callow wrote:
> On 14/12/2010 18:19, Tim Johansson 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.
> I'm with Gregg. I do not understand why toDataURL is an issue as the browser must already have the pixels for the reasons Gregg has stated. Just define toDataURL to return the pixels the browser is using for compositing. If the application calls it during a render period, it will get the content from the previous frame or the initial canvas color.
In the iOS implementation compositing is a system operation. When you give up control of a buffer you are giving it to a separate system process and so you lose control of that buffer. Because compositing is asynchronous, attempting to read its pixels would lead to inconsistent results. Sometimes you might see the correct values, other times that buffer might have been given to another process and its contents changed.
I think it's important to use an example from the mobile space like this because that is where maintaining peak performance is most critical.
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: