The default varies between OpenGL and OpenGL ES, so try to force it to what
the app actually requested with SDL_GL_FRAMEBUFFER_SRGB_CAPABLE.
Fixes#14898.
If GL/Vulkan was loaded manually via a SDL_X_LoadLibrary() call instead of via window flags or through the GPU or renderer system, and there is no matching SDL_X_UnloadLibrary() call, the library instance won't be automatically unloaded while shutting down the video system, as the refcount won't go to zero, which can cause problems with some backends, and leaves a leaked DLL/SO handle when the global video object is destroyed.
Ensure that the libraries are unloaded after destroying the windows, but before shutting down the video backend, to prevent a leak and possible driver errors when shutting down the video backend.
This changes the default for SDL_GL_FRAMEBUFFER_SRGB_CAPABLE to -1 (for
"don't care"). Minor ABI break, but technically this never worked correctly.
Fixes#13055.
This made sense when switching between a window and an exclusive fullscreen video mode of the same dimensions, but it causes user confusion when the window changes size, and doesn't work well with Wayland. I've gotten this feedback from several sources, so we'll just go ahead and remove this behavior for now.
Fixes https://github.com/libsdl-org/SDL/issues/11577
When attaching a renderer (GL based specifically) to a window that was not created with the appropriate flags, the window would be destroyed and recreated to configure it for the desired rendering backend. While most of the issues with this have been mitigated over time, there can still be some undesirable side effects from doing so on certain platforms.
If the window was just created and was never configured for any graphics context, it is possible that the reconfiguration can be done without destroying the window first.
The Wayland implementation fixes an issue when creating a window with the fullscreen flag on wlroots based Wayland compositors, and can likely be extended to other platforms to avoid unnecessarily destroying/recreating a window in the very common case where a window is created, followed immediately by attaching a renderer.
In certain cases when moving fullscreen windows in scaled desktop configurations, the window origin might overlap two displays at once. Check if the window is at the origin of a specific display before falling back to the generic window rectangle check.
Fixes rare fullscreen window misplacement when moving fullscreen windows via a desktop shortcut while using the Wayland scale-to-display mode.
Trying to determine where a window should be made fullscreen from the size and position can be unreliable if the window exceeds the display bounds. Add additional checks with the following priority:
- If the window was positioned with a macro that explicitly passes a display ID, store and use the requested display as the explicit fullscreen target.
- Check if the window position is an exact match for any display origins, and use that display if found, as positioning a fullscreen window by moving it to the origin of the destination display is common behavior.
- Fall back to the existing center point check if the previous checks were not successful, as it is known behavior, and won't risk breaking existing clients that rely on it.
If attempting to switch to an exclusive mode while a fullscreen spaces transition is active, wait until the transition is complete before trying to apply the changes, or the window can wind up in a weird, broken state if a mode switch occurs while in a fullscreen space.
This reverts commit ee8f2861e7.
It turns out that the problem is elsewhere, related to needing to block mode changes until spaces transitions are complete.
This still logs backend choices, but we might use it for other things. For
example, what Android device is being used, or all the devices we enumerated,
etc.
Ideally this eventually logs all the stuff we often have to ask followup
questions about.
macOS sends a focus loss event when the dialog is created, which causes SDL
to try to minimize the window, which confuses the entire system. So in this
special case, don't do the minimization.
Fixes#13168.
