[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL support for high bit depth rendering & display



Oh, the blending thing is an interesting point. If one is rendering to 2_10_10_10, does SRC_ALPHA get converted to 2-bit precision before the blending operation is performed? It seems like the answer would have to be "no" in order for this format to be generally useful for rendering.

On Wed, Sep 19, 2012 at 4:20 AM, Florian Bösch <pyalot@gmail.com> wrote:
On Wed, Sep 19, 2012 at 12:47 AM, Matt McLin <mr.mclin@gmail.com> wrote:
Florian, I'm not sure I understood your question about existing extensions.  As far as I know, I don't need any particular extension to use 10bpc & higher texture formats in OpenGL 3.0.  For OpenGL ES 2.0, I believe the following extensions provide the formats I'm looking for:   GL_UNSIGNED_INT_2_10_10_10_REV_EXT and GL_EXT_texture_storage.  Perhaps inventing a WebGL version of these extensions would be a step in the right direction?
Well there's something I don't understand.  This is a texture format, so you get a 2_10_10_10 texture. At best you can specify this to be the target of a framebuffer. But your front-buffer would still be 8_8_8_8 so how do you get the frontbuffer to be 2_10_10_10?

Regardless as Jeff mentions, that's not the only issue. You have to imagine it like this:

render -> "frontbuffer" which is an FBO -> compositor that renders into -> yet another FBO -> speaks to the windowing system to blit the picture afaik. If you're using 30-bit colors you only have 2-bit alpha, but the compositor needs more alpha. So the whole pipeline would have to switch to floating point textures in order to be able to convey the required information to composit a 2-10-10-10 picture that comes out on the other end correctly. It's not gonna help if the compositors buffers are 8-8-8-8 or if the compositor is only using 4 levels of alpha.



--
Jeff Russell
Engineer, Marmoset
www.marmoset.co