[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Proposed change to WebGL spec section 4.2 (Security Origin Restrictions)
On Oct 5, 2010, at 3:23 PM, Steve Baker wrote:
> I would just add that there are plenty of other reasons to want to read
> back the frame buffer. Brian's case is a common one - but there are
> lots of others.
> * WebGL does not (yet) support occlusion testing - and many of the
> hardware implementations of OpenGL-ES don't support smart Z skip-over -
> so occlusion culling can produce big performance wins. All of the many
> applications of occlusion testing have to be replaced by reading back
> the frame buffer. Since occlusion culling is an exceedingly powerful
> speed-up technique for low end systems - it's likely to be needed in
> phone applications. On desktop systems, reading back pixels is
> something we strive to avoid because it's so slow - but on low end
> machines, the frame buffer memory is likely to be a part of main memory
> - and that makes it fast enough to be usable again.
Don't be so sure about that. With the tile based renderers common on mobile hardware, memory is shared, but it is still incredibly slow to flush the pipe and read back pixels.
> * In some of the work I do in my paying job (military simulation - which
> is not WebGL-based **yet** but easily could become so) we do things like
> analysing the content of the frame buffer using statistical or image
> recognition techniques which mimic what real world weapon systems and
> sensors do. Doing this in shader code is tricky - but even when you
> can, you generally need to read back the results at some point.
> * I have built some proof-of-concept demo's showing massively parallel
> physics calculations and collision detection being done in a standard
> OpenGL shader (not using CUDA) - and that too typically requires some
> read-back from the frame buffer at the end of the process. Doing game
> likely to want to use the GPU whenever possible.
> * Ray-casting for picking really only works well when the objects are
> solid, opaque kinds of things. When you have an alpha texture cutting
> out the shape of (say) a tree, doing ray casting tells you that the user
> clicked on the tree polygon - when in fact he was clicking on the object
> behind the tree - through one of the large transparent bits. The ray
> caster could (in principle) simply look at the alpha plane of the
> texture - but with increasing shader sophistication, being able to
> figure out the transparency of a particular point on a triangle rapidly
> veers towards impossibility.
> As for issues of 'tainted' images - I have no clue - but for sure we
> need to be able to read back pixels from the frame buffer in a wide
> variety of applications.
All this makes me wonder if all query operations on the framebuffer need to be disallowed for a tainted framebuffer. For instance, GL_ARB_occlusion_query (which we don't support now, but conceivably could in the future) gives the author information about the contents of the framebuffer. Could a clever author somehow use this to determine the color values of a texture? If so, we would have to disallow this extension or at least access to the occlusion query results if the framebuffer is tainted.
I think we should just bail and let CORS sort this out :-)
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: