[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] readPixles() can't access float values (OES_texture_float interaction)
On Wed, Sep 14, 2011 at 2:42 PM, Chris Marrin <email@example.com>
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.