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

Re: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb

On Jun 15, 2016, at 7:00 PM, Florian Bösch <pyalot@gmail.com> 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.



Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail