[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 Mon, Sep 19, 2011 at 4:29 PM, Kenneth Russell <firstname.lastname@example.org>
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.
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.