[Public WebGL] readPixles() can't access float values (OES_texture_float interaction)

Chris Marrin [email protected]
Wed Sep 14 11:42:05 PDT 2011

On Sep 13, 2011, at 4:53 PM, Glenn Maynard wrote:

> On Tue, Sep 13, 2011 at 7:22 PM, Mark Callow <[email protected]> wrote:
> Doing this goes against the long standing principle of uniformity across implementations.
> First off, the much longer-standing principle of Web APIs is that once an interface is released to the public and used in the wild, it's there to stay; breaking APIs should only be done for very serious reasons, usually security-related.  APIs being released, used by developers, and then removed out from under them destroys developer confidence in the platform.

Did I miss part of the conversation? Is there an existing WebGL API that is being proposed to be removed?

> Second, there's no "principle of uniformity" in WebGL.  If there was, the dozen or so MAX_ constants wouldn't be there--all implementations would have the same maximum texture size, TUs and so on, with no possibility for them ever being increased.  There would be no extension mechanism at all.  These mechanisms exist precisely because the hardware underneath implementations has varying capabilities, and it would be disastrous to limit WebGL to the lowest-common-denominator of hardware.

There's a difference between varying levels of support of a feature and its existence. Hopefully we can all agree that before a new feature is added via the extension mechanism it should have reasonable support on a reasonable variety of hardware. That doesn't mean we can't add an extension that doesn't have universal support, but we should be careful to avoid adding esoteric features too early. 

> It's acceptable, and desirable, to limit the variation exposed to scripts in the absence of explicit opt-ins, to minimize *accidental* dependancies on features not available on low-end hardware.  (I think this should even have been done for eg. MAX_TEXTURE_SIZE and so on: have a baseline profile with MAX_TEXTURE_SIZE = 2048 or so, for example, with larger textures being rejected unless an eg. WEBGL_DESKTOP_PROFILE_2011 extension is loaded to explicitly indicate that you're raising the profile required by your program.)  It's not acceptable, however, to prevent people from writing games and applications targetting desktop hardware because you don't want people creating anything that doesn't work on your phone.
> The facts of the matter are that there is NO mobile GPU design
> This is WebGL, not WebMobileOnlyGL.  Limiting its usability so drastically would severely limit WebGL's chances of gaining broad acceptance by developers.

We should try to avoid overstating the situation. If we were to try to avoid features that don't exist on mobile hardware, we would limit WebGL somewhat, but not "severely". Mobile hardware is pretty capable and allows a huge amount of interesting content to be written. All of the current WebGL extensions are supported by the hardware in all recent iOS devices (3Gs and up), for instance. 

In this particular case, we're talking about supporting floating point frame buffers. Mark's right that none of the current generation of mobile hardware supports it. But it's also not universally supported in desktop hardware. Most notably from my reading is that none of the Intel Graphics chips support it. So to me it feels a bit early to add it to WebGL. But I'm not completely against it.

[email protected]

You are currently subscribed to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:
unsubscribe public_webgl

More information about the public_webgl mailing list