On Thu, Sep 15, 2011 at 2:34 PM, Mark Callow <firstname.lastname@example.org>
What other platforms do you have in mind?
Native development, middleware engines and anything else that can provide a more reasonable feature lag.Â If people can't accomplish what they want with the Web platform, they'll use something else.
I also just don't see the advantage--so long as optional features
are always implemented as extensions, to prevent unintentional
testing variables; as long as they're only added when they have a
stable OpenGL interface to follow; which have been shown to be of
value (hopefully implied by the previous).
As currently specified this particular feature can easily be used
without the developer realizing that it is an optional feature
lacking wide support.
Sure--that's a bug, in my opinion, though possibly one it's too late to fix.Â I mentioned this and cut it out because it seemed tangental, but I think that as many optional features and implementation variations as possible should be represented by a mandatory extension check.Â For example, it would have been good for the feature of rendering to a FP buffer to be exposed with "OES_texture_float_rendering".Â (This doesn't mean each needs its own spec; a single extension spec could define several extension strings, where it's editorially sensible.Â This is unlike OpenGL, due to WebGL's new policy of required extension queries.)Â I wouldn't personally object to this being done now for this feature, but it would obviously break existing code.
On the same token, it would be nice to have, for example, a "OES_profile_desktop_2011" extension, specifying values for MAX_TEXTURE_SIZE, MAX_TEXTURE_IMAGE_UNITS, and so on.Â If no profile extensions are enabled, all of these values would be clamped to the lowest-common-denominator; similarly, "profile_mobile" or "profile_advanced".Â As is, the same problem exists here--developers can unknowingly write software that depends, for example, on more TUs than some users have.
This means that as much of the variation between systems as possible is represented by explicit extension strings.
(Some variables are probably very hard to impossible to specify precisely, eg. fragment program size limitations.)
The OES_texture_float extension and the original WebGL version
thereof do not add support for floating point rendering. It is an
accident that some WebGL implementations chose to do so. There is no
OES or ARB extension that is the equivalent of the current WebGL
texture float extension so one cannot say it is mature and proven.
Rendering to floating-point textures with OpenGL is clearly a mature API, with proven functionality; that's the metric I was offering for considering exposing something to WebGL.