[Public WebGL] readPixles() can't access float values (OES_texture_float interaction)
Tue Sep 20 10:39:00 PDT 2011
On Mon, Sep 19, 2011 at 1:49 PM, Glenn Maynard <[email protected]> wrote:
> On Mon, Sep 19, 2011 at 4:29 PM, Kenneth Russell <[email protected]> wrote:
>> The developer has already expressed the intent to use optional
>> functionality by enabling the OES_texture_float or
>> OES_texture_half_float extension in his or her WebGL application.
> He's expressed the intent to use the specific optional behavior that the
> extension defines. This is optional behavior *within* that optional
> behavior, which creates the original problem all over again. You can
> require it without realizing you're using functionality that itself is
> optional--it's a separate testing variable. You're back at square one.
>> This is correct -- a WebGL implementation would have to try creating a
>> floating-point texture and attaching it to an FBO to know whether or
>> not to expose a hypothetical "WEBGL_render_texture_float" extension.
> That's not what I mean. If it was just that, then I'd agree that it should
> be an extension.
> The problem I'm referring to is that even if an implementation has support
> for FP render targets, it may, for example, not support them with stencil,
> or only support them with a depth buffer of a certain resolution. Just
> checking that it supports FP render targets isn't enough to guarantee your
> actual renderbuffer will work; you need to check that it works with the
> actual configuration you're using. I don't think this is a problem that can
> be fixed with the extension mechanism; it has too many axes.
Correct -- this is why I don't think we should spend the time and
implementation effort specifying a new WebGL extension defining the
ability to render to fp texture. Earlier in the development of the
WebGL spec, it was necessary to hide differences between separate and
packed depth+stencil renderbuffers. See
http://www.khronos.org/registry/webgl/specs/latest/#6.5 . Originally
we had hoped to catch the attempt to attach bad combinations of
renderbuffers at attachment time (framebufferRenderbuffer,
framebufferTexture2D) and return INVALID_OPERATION, but the problem is
that you can redefine a renderbuffer's or a texture's storage after
it's been attached to an FBO. Therefore the only way to report the
fact that a given texture or renderbuffer type isn't supported is via
checkFramebufferStatus (and generating INVALID_OPERATION during draw
Consider this. Define a "WEBGL_render_texture_float" extension that
has to be enabled to render to FP textures, and the WebGL
implementation guarantees that if that extension were supported, then
some combination including an FP color attachment will work. If this
extension isn't enabled, and the app illegally tries to attach an FP
texture as a color attachment to an FBO, the only way to report this
error will be via checkFramebufferStatus, which the app should be
calling anyway. The error can not be caught earlier (i.e., during
framebufferTexture2D) for the reasons described above.
In summary, I think that adding another extension in this area would
just add a meaningless hoop for application developers to jump
>> Doing so isn't technically difficult, but I think that there are
>> higher priority issues for WebGL implementors to deal with at this
>> point -- for example, finishing the current conformance suite so that
>> it is actually possible to ship compliant implementations.
> If this was to be done at all, then it should be prioritized. The longer an
> incompatible change is delayed, the more work it creates for people.
> Glenn Maynard
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:
More information about the public_webgl