[Public WebGL] WEBGL_compressed_texture_s3tc_srgb

Mark Callow [email protected]
Wed Jun 15 03:19:03 PDT 2016

> On Jun 15, 2016, at 7:00 PM, Florian Bösch <[email protected]> wrote:
> If you ever where to support sRGB front buffers in WebGL, the browser would have to re-encode the linearly read out value from the sRGB texture it uses as a stand-in for a frontbuffer from the WebGL context explicitely into sRGB space again manually (the OS isn't going to help him any with that). As it stands, that capability does not exist, and so the application programmer has to do that job, and the job is identical, perform a re-encode to sRGB from the linear value read out from the sRGB texture and blit it as non-linear value onto the WebGL front buffer. This is why the distinction matters. Because the browser (or the application programmer) can only emulate (manually) EGL agnostic behavior, with a non colorspace agnostic bitmap surface. This is a problem you do not have in native EGL because EGL is specified to be agnostic, so a native programmer doesn't have to care.

A solution is for the browser to use an sRGB default framebuffer for its final output. It can use linear or sRGB textures for the canvas backing stores and page backing store as it wishes (ignoring issues of backward compatibility with the current broken situation). The GPU will convert everything to linear during compositing and back to sRGB again when writing the composited result.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20160615/d3dc9671/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20160615/d3dc9671/attachment.asc>

More information about the public_webgl mailing list