SDL2 and 3: wgl GLES 2.0 context by default created as srgb capable with no way to disable it

[edo9300]

When initializing an OpenGL ES 2.0 context on windows via wgl, the context is created with srgb capability enabled by default, which my application doesn't support. The issue comes with the fact that by default the WGL_FRAMEBUFFER_SRGB_CAPABLE_ARB flag is "don't care" per the OpenGL spec, but sdl only explicitly set it if the value is nonzero

SDL/src/video/windows/SDL_windowsopengl.c

Lines 648 to 651 in d16371b

	if (_this->gl_config.framebuffer_srgb_capable) {
	*iAttr++ = WGL_FRAMEBUFFER_SRGB_CAPABLE_ARB;
	*iAttr++ = _this->gl_config.framebuffer_srgb_capable;
	}

so the application will receive an incompatible context.
Would always setting that value, even when 0 be an acceptable fix? And in case, should the same be done in the other opengl context creation functions?

[icculus]

Hmm, so this is more complicated than that:

• There's True or False options for this (omit the attribute completely for "don't care").
• We don't have a "don't care" option, as far as SDL's docs go; it defaults to zero, which means "don't want a sRGB capable context".
• We probably shouldn't set this at all unless the WGL_ARB_framebuffer_sRGB extension is available. Likewise for X11.
• The X11 code doesn't set this the same way:

    if (_this->gl_config.framebuffer_srgb_capable) {
        attribs[i++] = GLX_FRAMEBUFFER_SRGB_CAPABLE_ARB;
        attribs[i++] = True; // always needed, for_FBConfig or not!
    }

• This code is still identical in SDL2.

So, do we want a "don't care" option? What would it be, -1? Strictly speaking, the Windows code is doing the right thing, assuming the extension is available: we're setting it to Yes or No, and it was a mistake for the app to set this to anything other than 0 or 1.

[icculus]

the context is created with srgb capability enabled by default, which my application doesn't support.

Also, it isn't clear to me how this is getting enabled by default, it should be disabled by default.

[edo9300]

The Windows code is doing the right thing, assuming the extension is available: we're setting it to Yes or No, and it was a mistake for the app to set this to anything other than 0 or 1.

This is not what the code is actually doing tho, the setup code is checking _this->gl_config.framebuffer_srgb_capable, which is not something set by checking the extension availability, but by the gl option callback

SDL/src/video/SDL_video.c

Lines 5043 to 5045 in 04aa74b

	case SDL_GL_FRAMEBUFFER_SRGB_CAPABLE:
	_this->gl_config.framebuffer_srgb_capable = value;
	break;

Should this if actually be checking for the extension to be available rather than for the gl config option be set?

The X11 code doesn't set this the same way:

it manually sets the attribute to true, but the logic ends up being the same as wgl (since in wgl the branch is taken only if the flag is already nonzero)

Also, it isn't clear to me how this is getting enabled by default, it should be disabled by default.

It's likely some difference in handling desktop gl and gles contexes, you can actually see this happening even with the testgles2 program, disable the rotation of the cube, and run it once with the current sdl defaults, and another time by force setting the srgb to false

Unset:

Explicitly set to 0 (by changing the "offending" code in sdl to allow it):

• We don't have a "don't care" option, as far as SDL's docs go; it defaults to zero, which means "don't want a sRGB capable context".

I'd guess this is an issue specific to GLES via wgl (which i don't think is something that has been really used so far), and likely other implementations default to srgb off (hence explicitly setting it to 0 would be the right default for sdl).
I suppose the various platforms should be checked with the gles2 test program to see what the defaults are, and if they all default to srgb off rather than on, it'll confirm that wgl is the only outliar.

[edo9300]

Worth noting that i'm currently using a radeon 570 nitro+ (so these results come from amd drivers for this card)

[icculus]

Ah, okay, I see what's happening. Basically the assumptions in this bug report are correct: we should definitely set this to True or False if the extension is available, because the default for "don't care" at the driver level seems to be to definitely favor sRGB capable contexts.

But, sad news: my Nvidia 4070 RTX reports it has the extension, but explicitly setting the attribute to 0 or 1 still gets me an sRGB-capable context (and both look like the second image you posted when I disable rotation in testgles2.c: darkened top-right corner). It's not clear to me if this is an Nvidia thing in general or a GLES quirk on Nvidia's drivers. I don't have an ATI GPU to test on here.

So I guess we'll make the fixes and see if it helps you, but you might be out of luck in general here.

[icculus]

(Googling suggests Nvidia has been this way for a long, long time.)

[icculus]

Although changing this is going to surprise people when their output gamma changes...we should change the default from 0 to -1, and treat it as "don't care," which is more or less how this has worked thus far for not touching that attribute.

[edo9300]

But, sad news: my Nvidia 4070 RTX reports it has the extension, but explicitly setting the attribute to 0 or 1 still gets me an sRGB-capable context (and both look like the second image you posted when I disable rotation in testgles2.c: darkened top-right corner).

This sure lools weird, the 2nd pic is a non sRGB capable context, so why is the driver telling you it enabled the sRGB context while also rendering things as non sRGB? If you set the attribute to 1 expliciltly do you also get the dark corner?

[icculus]

Yes, same no matter what I set it to.

[edo9300]

So, tested on linux egl (with an intel igpu), and i get by default non srgb contexes (so 2nd image), and if i explicitly enable it, I get a proper srgb context that looks like the first image (both x11 and wayland).
So at least on that side things are consistent with having the default as "off"

[edo9300]

Yes, same no matter what I set it to.

Just to be sure, the driver tells you it's srgb capable even when you call SDL_GL_GetAttribute on it?
And on this side, i noticed that the flag isn't cleared either if the extension isn't availlable

SDL/src/video/windows/SDL_windowsopengl.c

Lines 553 to 561 in 195c518

	if (_this->gl_data->HAS_WGL_ARB_pixel_format) {
	_this->gl_data->wglChoosePixelFormatARB(hdc, iAttribs, fAttribs,
	1, &pixel_format,
	&matching);
	// Check whether we actually got an SRGB capable buffer
	_this->gl_data->wglGetPixelFormatAttribivARB(hdc, pixel_format, 0, 1, &qAttrib, &srgb);
	_this->gl_config.framebuffer_srgb_capable = srgb;
	}

(on egl instead it errors out on context creation, while uikit checks nothing)

[icculus]

Yes, the line...

_this->gl_data->wglGetPixelFormatAttribivARB(hdc, pixel_format, 0, 1, &qAttrib, &srgb);

...is setting srgb to 1 on Nvidia in both cases. Maybe it's defaulting the enable/disable of GL_FRAMEBUFFER_SRGB to a different value? I don't know at the moment. I'll double-check this later to make sure I'm not totally wrong.

[edo9300]

Looking at the docs, it seems that the query argument WGL_FRAMEBUFFER_SRGB_CAPABLE_ARB isn't to be queries with wglGetPixelFormatAttribivARB but wglGetPixelFormatAttribivEXT https://registry.khronos.org/OpenGL/extensions/ARB/ARB_framebuffer_sRGB.txt, so that check could actually be wrong