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

Glenn Maynard [email protected]
Mon Sep 19 12:32:44 PDT 2011


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.

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.

(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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20110919/8d05967d/attachment.html>


More information about the public_webgl mailing list