[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 22, 2010, at 5:58 PM, Gregg Tavares (wrk) wrote:
> ...I'll stop with the iOS stuff after this, promise :-D I just want to clarify for my own edification.
Cool and I'll stop answering after this :-)
> iOS can and never will be able to print? If it can then it will have access to the pixels. Even if it means re-directing the printer to memory, printing, and grabbing the pixels from the result.
Yes, it can print. That's a system level function. How and where it gets its pixels to print is none of my business.
> iOS can currently take a screenshot at any time. It seems like their must be some way of exploiting that to get the pixels back, even if it means writing a .PNG to memory and then loading and decompressing it.
System level function. The notion of reading and decoding a PNG image as a way of getting the current drawing buffer is not practical.
That's how preserveDrawingBuffer=true would most likely be implemented. It's an extra expense which the author would incur if this feature is enabled.
> So, one way or another I still kind of feel like their is a way to make readPixels, toDataURL, drawImage and texImage2D to always work even in iOS when preserveDrawingBuffer is false.
> but, assuming it's going to stay the way it is it still seems like what you get from those 4 functions needs to be defined at all times. At least it seems like the spec needs to define that they do not fail. Ie, they return something the size of the canvas. They do not throw, they do not generate errors and and they do not return unexpected sizes.
The spec currently states that the color buffer (the only buffer directly accessible) would return (0, 0, 0, 0).
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: