Doing this goes against the long standing principle of uniformity
across implementations. Allowing extensions cracked open the door
to non-uniformity. This decision blows it wide open. These demos,
that have wowed people to the extent of ignoring the long standing
principle, will likely only be seen by a minority of web users.
The facts of the matter are that there is NO mobile GPU design
that supports rendering to float buffers and only a single mobile
GPU design that supports rendering to half-float buffers. It will
be probably 2 years before this situation changes. Furthermore
determining whether or not a WebGL implementation supports such
rendering is a lot more complex than a simple query. I expect
there will be many developers who will get a nasty suprise after
deploying their applications when they find it does not work for a
substantial number of people.
There seems to be agreement among the WebGL WG members that enabling render-to-fp-texture functionality, where it can be supported, is crucial. Further, there's at least one ES 2.0 chipset that supports fp16 renderbuffers. Therefore, I've updated the WebGL extension registry's exposure of OES_texture_float and OES_texture_half_float (, ) to indicate that the WebGL versions of these extensions optionally allow these textures to be used as the color attachments to FBOs. I think that any changes related to reading back of FLOAT pixels via readPixels should wait for a future revision of the WebGL spec.
begin:vcard fn:Mark Callow n:Callow;Mark org:HI Corporation;Graphics Lab, Research & Development adr:Higashiyama 1-4-4, Meguro Ward;;Meguro Higashiyama Bldg 5F;Tokyo;;153-0043;Japan email;internet:firstname.lastname@example.org title:Chief Architect tel;work:+81 3 3710 9367 tel;fax:+81 3 5773 8660 x-mozilla-html:TRUE url:http://www.hicorp.co.jp, http://www.mascotcapsule.com version:2.1 end:vcard