sRGB findings on various platforms

For the past while I've been working on and off on turning the current sRGB colorspace support into full-fledged color space support, with a focus on EGL (Wayland desktop and Android phones). As it turns out there are quite a few backend differences that only make this feasible for the EGL backend. But before we get into some design questions I'd like to ask (separate issue), let's first look at sRGB as every backend and implementation has already gotten me totally confused. This is not really a Glutin issue but more of a general OpenGL ecosystem mess, though it might definitely be relevant to keep our implementation and documentation in check so I'm sharing it anyway.

The following was tested on a:

Sony Xperia 1IV;
RX 6800 Sway (ArchLinux);
Intel UHD 620 on Sway;
RX 6800 XT on Windows.

Preface

GL_FRAMEBUFFER_SRGB is a feature that performs linear->sRGB conversion when writing to sRGB textures / framebuffers. It has no effect when the target is already linear (or so it is documented...);
This color space is queried using FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING;
I think support for GL_FRAMEBUFFER_SRGB is what is queried/filtered via FRAMEBUFFER_SRGB_CAPABLE_* on WGL and GLX. Though it works regardless if it is not capable (??);
For X11 there is no way to configure a color space via GLX. Perhaps this can be set on a window beforehand?

Android EGL

Default color space is linear;
GL_FRAMEBUFFER_SRGB (automatic linear->srgb conversion when writing to an srgb framebuffer) is on by default;
Querying FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is not supported (it's GLES 3.2 though...);
Changing the color space via EGL_GL_COLORSPACE to EGL_GL_COLORSPACE_SRGB appropriately uses the default FRAMEBUFFER_SRGB conversion, the image is now brighter;
- The image stays at the original darker color when in GL_COLORSPACE_SRGB with gl.Disable(gl::FRAMEBUFFER_SRGB).

:+1:, all working as expected.

Wayland EGL (AMD Mesa)

GL_SRGB is always reported by FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING;
Changing the color space via EGL_GL_COLORSPACE makes no difference (color stays the same, COLOR_ENCODING always returns GL_SRGB);
GL_FRAMEBUFFER_SRGB is off by default;
Enabling GL_FRAMEBUFFER_SRGB always makes the image brighter (makes sense given that the framebuffer is always considered to be in GL_SRGB colorspace);
The EGL_(GL_)COLORSPACE attributes follow which color is being set in CreatePlatformWindowSurface*.

Wayland EGL (AMD ProGL)

(using progl command)

Default color space is GL_LINEAR according to FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING;
EGL_COLORSPACE is EGL_GL_COLORSPACE_SRGB, but EGL_GL_COLORSPACE is EGL_GL_COLORSPACE_LINEAR;
Setting EGL_COLORSPACE has no effect;
Setting EGL_GL_COLORSPACE to SRGB correctly makes COLOR_ENCODING return GL_SRGB;
- Turning on GL_FRAMEBUFFER_SRGB makes the image brighter (only when the color encoding is sRGB :+1:).

X11 (AMD Mesa)

COLOR_ENCODING is always GL_SRGB;
Alternating configs are sRGB-capable;
GL_FRAMEBUFFER_SRGB makes the output lighter on every config (even those that are not "sRGB capable").

X11 (AMD ProGL)

COLOR_ENCODING always reports GL_LINEAR;
No config is "sRGB-capable" (??);
_Enabling GL_FRAMEBUFFER_SRGB makes the output bright (this should not be the case for linear framebuffers?!)_.

Wayland EGL (Intel UHD 620 on Mesa)

FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING is always GL_SRGB;
EGL_COLORSPACE is EGL_COLORSPACE_SRGB, while EGL_GL_COLORSPACE is EGL_COLORSPACE_LINEAR;
- Changing either of these has no effect on COLOR_ENCODING;
Enabling GL_FRAMEBUFFER_SRGB always makes the image brighter (as expected for COLOR_ENCODING = GL_SRGB).

X11 (Intel UHD 620 on Mesa)

Also alternating configs which are "sRGB-capable";
On all configs COLOR_ENCODING is GL_SRGB;
FRAMEBUFFER_SRGB is disabled by default, but enabling it always makes the image brighter.

Windows (RX 6800 XT)

COLOR_ENCODING is GL_LINEAR;
GL_FRAMEBUFFER_SRGB is disabled;
Enabling GL_FRAMEBUFFER_SRGB makes the image brighter (again, weird for a linear color encoding...);
All configs are sRGB-capable;
WGL_EXT_colorspace is not in the list of supported extensions;
As expected, querying WGL_COLORSPACE_EXT via wglGetPixelFormatAttribivARB() always fails;
However, setting WGL_COLORSPACE_EXT to WGL_COLORSPACE_SRGB_EXT via wglChoosePixelFormatARB():
- Makes COLOR_ENCODING return GL_SRGB :+1:;
- Makes the image darker 👍;
- Enabling GL_FRAMEBUFFER_SRGB gets the image back to normal colors 👍.
- Very nice (especially that the image gets darker, means the compositor actually interprets the data differently as we expect...), but super confusing once again.

Changing the color space via EGL_GL_COLORSPACE makes no difference (color stays the same, COLOR_ENCODING always returns GL_SRGB);

SRGB setting in EGL is mostly when you're dealing with GLES context and not OpenGL from what I understand, because you can't manipulate with attachment function in OpenGL.

Setting EGL_COLORSPACE has no effect

It should have it with gles context..

I'm not that familiar with real OpenGL use.

SRGB setting in EGL is mostly when you're dealing with GLES context and not OpenGL from what I understand, because you can't manipulate with attachment function in OpenGL.

Should be available on both afaik: https://registry.khronos.org/EGL/extensions/EXT/EGL_EXT_image_gl_colorspace.txt

Setting EGL_COLORSPACE has no effect

It should have it with gles context..

I'm not that familiar with real OpenGL use.

Oh no, more variables; maybe I should retest this all again and put the results in a big table that's a bit more clear. More on that later.

Replying to the rest of your sRGB comments from https://github.com/rust-windowing/glutin/issues/1653#issuecomment-1858715266 here:

There does not seem to be a way to query which color spaces a certain config/surface supports, [..]

This is present because some platform determine the framebuffer type at the surface/context creation time and you can't switch at runtime.

Do you imply from *FRAMEBUFFER_SRGB_CAPABLE_ARB/EXT that the framebuffer must be an SRGB texture? Renderdoc seems to agree with that thought but https://registry.khronos.org/OpenGL/extensions/ARB/ARB_framebuffer_sRGB.txt seems to suggest that it only exposes whether sRGB blending/conversion is available (which only makes sense on sRGB surfaces, so implying that it's sRGB)?

As outlined in this issue that sRGB blending/conversion seems to be applied to non-sRGB-capable configs. And COLOR_ENCODING is not always representing the actual value of a texture. Do you think I am querying it correctly?

gl.GetFramebufferAttachmentParameteriv(
    gl::FRAMEBUFFER,
    gl::FRONT,
    gl::FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING,
    &mut ce
);

Basically GLES and that's why we have those checks, mostly. Since when you have OpenGL context you don't have GL_ARB_framebuffer_sRGB.

Isn't it the other way around? GL_ARB_framebuffer_sRGB is in the OpenGL extensions but not in ES. They have https://registry.khronos.org/OpenGL/extensions/EXT/EXT_sRGB.txt and https://registry.khronos.org/OpenGL/extensions/EXT/EXT_sRGB_write_control.txt.

After all I also had to switch gl_generator from Api::Gles to Api::Gl to use that extension and get the constant for FRAMEBUFFER_SRGB.

Should be available on both afaik

Hm, I know that with gles you can't change buffer colorspace at runtime, at least with gles2, maybe you can with gles3. It should be testable if you pick ES context and play with srgb on a surface, though, you likely did that already.

Do you imply from *FRAMEBUFFER_SRGB_CAPABLE_ARB/EXT that the framebuffer must be an SRGB texture?

Not sure what you mean. I was saying that some platforms define buffer type at surface creation, e.g. EGLSurface with gles2 context. That's the only reason we have sRGB API on a surface creation.

Hm, I know that with gles you can't change buffer colorspace at runtime, at least with gles2, maybe you can with gles3. It should be testable if you pick ES context and play with srgb on a surface, though, you likely did that already.

I can get an ES 3.2 and OpenGL 4.6 context on the RX 6800 XT from Mesa. Via Wayland EGL, on OpenGL 4.6, as above FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING always returns GL_SRGB. However, renderdoc says that it is R8G8B8A8_UNORM as opposed to _SRGB when I set EGL_GL_COLORSPACE to GL_COLORSPACE_LINEAR. GL_FRAMEBUFFER_SRGB always facilitates a conversion though, the image looks the same regardless of the colorspace.

(Maybe I am reading FRAMEBUFFER_ATTACHMENT_COLOR_ENCODING from the wrong place?)

On GLES3 on the same Mesa driver it works better: the linear->sRGB conversion only happens when I set EGL_GL_COLORSPACE to EGL_COLORSPACE_sRGB. Renderdoc also confirms SRGB vs UNORM as texture format.

On GLX on this Mesa driver I get identical behaviour.

Not sure what you mean. I was saying that some platforms define buffer type at surface creation, e.g. EGLSurface with gles2 context. That's the only reason we have sRGB API on a surface creation.

Only EGL does this, WGL has a way to set it on the config, GLX doesn't expose any parameters.

I think I should leave this here and focus on EGL colorspace support, instead of messing with broken sRGB support :)

https://registry.khronos.org/EGL/specs/eglspec.1.5.pdf

Only OpenGL and OpenGL ES contexts which support sRGB rendering must respect requests for EGL_GL_COLORSPACE_SRGB, and only to sRGB formats supported by the context (normally just SRGB8) Older versions not supporting sRGB rendering will ignore this surface attribute. Applications using OpenGL must additionally enable GL_FRAMEBUFFER_SRGB to perform sRGB rendering, even when an sRGB surface is bound; this enable is not required (or supported) for OpenGL ES.

Strange because I need that flag on ES to get sRGB conversion working :sweat_smile:

rust-windowing / glutin