[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] WebGL support for high bit depth rendering & display
A few thoughts:
- I do think that 10_10_10_2 texture formats are useful (also, vertex formats). They are included in ES 3.0, so I would expect them to appear in the next version of WebGL. I also think that it is a straightforward enough extension that someone who really cared could write the extension. I would guess that texturing and rendering targets would have to be separate. It seems you want the latter, and would probably need to add language to specify something about the context's drawing buffer. AFAIK, there isn't a way to specify the desired color bit depth on getContext.
- There was a claim that WebGL is the last link in the 30-bit chain, but I would be more concerned about browser compositors. In particular, they require destination alpha to work correctly, so 10_10_10_2 is probably unsuitable as a rendering format for them. The WebGL surface and final browser surface would probably have to be 16-bit floats (I don't think 16-bit fixed is common, except maybe as an accumulation buffer format).
- You don't necessarily need a >8-bpc textures to want >8-bpc results. For example, the result of resolving anti-aliased 8 bpc multisample buffers is ~10 bpc.
- While supported, 30 bit displays are pretty rare (a lot of the claim to be 10-bit, but only for internal processing and only have 8-bit panels). You need a fancier graphics card, hooked to a fancier monitor over DisplayPort. The reach (and therefore the necessity for something like WebGL) is unfortunately questionable. I think it would be pretty cool, though :)
On Wed, Sep 19, 2012 at 11:48 AM, Matt McLin <email@example.com>
Ah, I was referring to a 16-bit per channel integer format, not floating point.
On Wed, Sep 19, 2012 at 8:41 AM, Jeff Russell <firstname.lastname@example.org>
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)?
Negative values wouldn't be clamped to 0, which could interact later on with blending. Floating point buffers also do interesting things with NaN values.