SDL2: Windows with SDL_WINDOW_RESIZABLE and no SDL_SetWindowMinimumSize() shouldn't ever spawn with parts cut off

[ell1e]

Windows created with SDL2 which have a SDL_WINDOW_RESIZABLE flag and no SDL_SetWindowMinimumSize() that requires them to do so, shouldn't ever spawn with parts cut off. Sadly, this happens anyway at least with the wayland video driver (I haven't tested any other). This seems to mean I either need to try to detect screens manually and then spawn on one with a shrunk size if needed that fits, or manually resize it down somehow after spawning, all of which seems both error prone to do manually and something which most if not all apps would want to be doing out of the box. Therefore, I think it would make sense to patch this in SDL2 and SDL3.

Tested with SDL2 version: 2.30.9

Tested on system: postmarketOS 24.12 Linux

Tested with compositor: kwin_wayland 6.2.4

[Kontrabant]

Some windowing systems will already clamp window sizes as a matter of policy, while others allow unbounded window sizes. In general, SDL will attempt to give clients what they ask for, and leave any restrictions to the underlying platform.

We could add a window property in SDL 3 that would keep the window clamped within the usable desktop bounds. I don't think it's going to happen for SDL 2 though.

[ell1e]

But why would make an app a window SDL_WINDOW_RESIZABLE but then intentionally spawn it oversized? I can't really think of much situations where this would be intended for a resizable window.

While a property would be useful for configuring it, it probably should also be the default for SDL 3 unless the window either isn't resizable, or the app opts out. Unless there's a legit common use for this I'm not seeing.

[Kontrabant]

Because that's the size they asked for, even if resizable, so that's what SDL attempts to give them. Doing so otherwise can lead to expensive swapchain recreation from redundant resizes as apps fight with the window manager trying to get what they want.

Games in particular will sometimes create a fullscreen-sized window before actually entering fullscreen.

[ell1e]

But does any app fight over that for a resizable window, which isn't the default? That seems like something that doesn't really happen in reality. I realize this is a "famous last statement" situation, but I honestly can't think of a situation where that would make sense.

[ell1e]

The reason I'm so persistent on this is that I have multiple devices with relatively small screens, and I regularly encounter perfectly resizable apps that just spawn too large and then it becomes extremely clumsy as a user to fix that. This isn't a rare occurrence, sadly. I think it would therefore be potentially useful, to try to avoid that in the underlying toolkits by default for situations where this is sensible to do.

[slouken]

This seems like a reasonable change for SDL3.