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

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



Hi guys,

Indeed, extensions like the GL_UNSIGNED_INT_2_10_10_10_REV_EXT are only a provision for a source texture format, not a render target (can you tell I come from DirectX background?), which is why I only said this could be a "step in the right direction", but certainly not the answer.  

As for alpha blending, my understanding was that HTML5 Canvas is typically not retaining/using alpha in the destination anyway (instead it alpha-blends the source into the dest from back to front), but maybe I'm wrong on this.  In any case, I would be happy with an A16R16G16B16 backbuffer if that resolved the alpha concerns.

I would also expect the WebGL code to be able to specify backbuffer format when requesting the WebGL context, so then the web app can decide whether it needs a format with extra alpha bits or not.  Is there already some mechanism for specifying alternate WebGL context format, if I wanted a 16bpp backbuffer, for example?  I didn't find anything like this in the context creation flags.  To me this implies that the browser is allowed to select whatever backbuffer format it wants to, provided it allows the rest of the WebGL code to meet spec.

Try thinking this way: if the browser created an A16R16G16B16 backbuffer (on gfx HW that supported this, of course), but all the rest of your WebGL code remained unchanged,  can you think of a scenario where the rendering did not come out correctly (as compared to A8R8G8B8 backbuffer)?

Regards, Matt


On Wed, Sep 19, 2012 at 7:19 AM, Jeff Russell <jeffdr@gmail.com> wrote:
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.

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?