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

Glenn Maynard [email protected]
Wed Sep 14 16:23:28 PDT 2011

On Wed, Sep 14, 2011 at 2:42 PM, Chris Marrin <[email protected]> wrote:

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

The argument was against the decision Kenneth described: retaining the
ability to render to floating-point framebuffers.

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.

Sure, but it may be harder to agree on what "reasonable support" means.  I'd
consider a feature supported by both nVidia and ATI, and which is mature
enough to have an ARB extension, to have reasonable support.  If it doesn't
yet have an ARB extension (or specification by OpenGL itself), then it
probably isn't mature enough for WebGL adaptation either, of course.

 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.

My GeForce 6600 supported rendering to FP textures; that's 2004 hardware.
If WebGL doesn't add features until budget onboard systems support them, the
feature lag will approach a decade.  That seems like a severe problem to
me.  It's not that it makes WebGL useless; it's that it makes it
uncompetitive against other development platforms, which makes the decision
to base development on WebGL a more difficult one.

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).  OpenGL itself has always been conservative with promoting
extensions to ARB--leave experimentation to vendor extensions--and of course
WebGL should follow that lead.

Glenn Maynard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110914/ffac50dd/attachment.html>

More information about the public_webgl mailing list