Fix Windows OpenGL: Fallback to non-sRGB when sRGB not supported

[john-parton]

Previously, if sRGB framebuffer was requested but not available on Windows, the pixel format selection would fail silently with num_formats=0, leading to undefined behavior with an invalid pixel format.

This commit adds:

• Proper validation that wglChoosePixelFormatARB found a matching format
• Graceful fallback: retry without sRGB if initial request fails
• Warning message to inform users when falling back to non-sRGB

[john-parton]

This resolves #220

It's a relatively simple workaround. As far as I can tell, the spec doesn't really say what happens if you use 0 as your value there, but I think 0 is really null/None in this context, so double checking and finding an actual appropriate value makes sense to me.

I didn't check the behavior on MacOS or Linux, as I wanted to keep the scope of this low, but there may be a similar issue.

[john-parton]

It looks like the behavior under linux to is to return as an error:

baseview/src/gl/x11.rs

Lines 190 to 192 in 237d323

	if n_configs <= 0 || fb_config.is_null() {
	return Err(GlError::CreationFailed(CreationFailedError::InvalidFBConfig));
	}

I think probably it would be better if Windows behaved the same and then I guess whatever downstream libraries from here would have to handle that gracefully by explicitly re-initializing.

[john-parton]

My preference is that this pull request be seriously considered, but I have provided a minimal alternate of propagating the error to the user here: #222 I'm not sure that pull request could even be considered done, but it's there if we want to pivot.

[prokopyl]

I think the ideal solution would be to chuck GL context creation out of Baseview and just use glutin, which has a way more robust and better-tested implementation.

However, that ideal solution requires a breaking change (and probably more discussion), so I'm putting that aside and looking at this only for bug-fixing in the context of releasing v0.1. 🙂

I have yet to still test this on my end, but I much prefer this fallback approach compared to the one you implemented in #222, for two reasons:

• As you explained, error detection and recovery would be very difficult for downstream crates, especially since we don't have proper error management at the moment and most things just panic.
• This is actually the approach used by glutin (i.e. silently dropping the value of the srgb flag in the config if not supported, at least on Windows). This should make baseview in line with the libraries that use glutin+winit (which I have verified to be the case for at least egui and Vizia)

I'll report back with my testing, and will close #222 in favor of this PR. 🙂

[prokopyl]

Code wise this looks good to me! 🙂

[prokopyl]

Can confirm this works as intended, both on Wine and on native Windows.

Thank you for this PR, as well for the in-depth investigation, it is much appreciated! 🙂