[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] 2.2 The Drawing Buffer requires 8 bit per color component
On Tue, May 29, 2012 at 12:46 PM, Gregg Tavares (社用) <email@example.com>
Actually, I'm not sure what the purpose of RGBA4/RGB5A1/RGB565 renderbuffers are, since you can just bind a texture with those formats. On the same token, what would be the benefit of supporting RGBA8 renderbuffers, instead of just binding a texture?
The purpose appears to be to give GPU vendors more ways to make crappy GPUs. :-p
According the OpenGL ES 2.0 spec
There must exist, however, at least one combination of internal formats for which the framebuffer
cannot be FRAMEBUFFER_UNSUPPORTED
That basically means that as long as 1 renderbuffer format works ZERO texture formats are required to work or visa versa. :-(
I was a bit confused reading the ES spec, so to walk through a bit:
ES's "implementation-dependent set of restrictions" framebuffer completeness clause only allows completeness to vary based on the internal format; it doesn't say that it can vary based on whether it happens to be a texture or a renderbuffer.
However, it seems like that's implied from the definition of internal formats. The internal format of a texture is a function of the arguments to TexImage2D. That means that if you create a renderbuffer and a texture with the same requested format, they might actually have different internal formats. That means the implementation is allowed to support only renderbuffer color attachments but not textures.
This seems like another reason WebGL needs a "capability profile" extension. ES doesn't provide the kinds of interoperability the web needs, and while hardware differences will always prevent WebGL from having the interop of other APIs, it can improve a lot on ES.