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

Kenneth Russell [email protected]
Mon Sep 19 13:29:44 PDT 2011

On Mon, Sep 19, 2011 at 12:32 PM, Glenn Maynard <[email protected]> wrote:
> On Mon, Sep 19, 2011 at 2:36 PM, Kenneth Russell <[email protected]> wrote:
>> I'm not in favor of adding a WebGL-specific extension that has to be
>> separately enabled in order to attach FP textures to an FBO. If there
>> were an ES20 extension defining FP framebuffer support, that would be
>> a different question.
> I disagree with the idea that WebGL shouldn't do this because ES doesn't.
> ES and WebGL have different policies for extensions, and I think WebGL's
> rationale for breaking from ES in this applies here as well: don't expose
> optional functionality unless it's explicitly enabled.

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.

> Note that this extension wouldn't be defining the behavior of floating-point
> rendering--defer to wherever it's currently defined.  It would be much
> simpler: the WebGL spec would give an explicit list of which formats can be
> bound to framebuffers, effectively a whitelist, and all the extension would
> do is append to that list.
> That said, there may be a different rationale for not doing this: for
> framebuffers, it's not enough.  An implementation might
> INCOMPLETE_ATTACHMENT at you even if it supports the framebuffer type--it
> might not like certain combinations of attachments, for example.  Even if FP
> framebuffers are supported, you'd still have to test on every device to make
> sure it likes the actual configurations you're trying to use, which defeats
> the purpose of having to query an extension.  I've always considered this
> the most glaringly flawed API in OpenGL; I don't know if ES is more
> restrictive about when implementations can throw this error than OpenGL is.

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.

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.


> (It's been a long time since I've looked at the OpenGL/ES specs.  If there
> are equivalency requirements that I'm not recalling--for example, "if
> framebuffers in configurations (COLOR1, DEPTH1) and (COLOR2, DEPTH2) are
> complete, then (COLOR2, DEPTH1) and (COLOR1, DEPTH2) must also be
> framebuffer complete"--then please remind me.  I don't think there are.)
> --
> 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:
unsubscribe public_webgl

More information about the public_webgl mailing list