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.

[ell1e]

I found out by accident today that this behavior already seems to be what happens even using SDL2 with SDL_VIDEODRIVER=x11 at least when using a KDE Plasma 6 Wayland sesssion. So perhaps this issue might actually be a Wayland regression.

[slouken]

Unfortunately this behavior is entirely up to the window manager, and even if we do things like clamp the window size to the usable desktop area, the window manager might add large window decorations and we'd still have part of the window be offscreen. I'm not sure how best to handle this...

[ell1e]

Perhaps you are correct, I filed a KWin/KDE bug now to see what they think of this issue: https://bugs.kde.org/show_bug.cgi?id=498221

[Zamundaaa]

Unfortunately this behavior is entirely up to the window manager, and even if we do things like clamp the window size to the usable desktop area, the window manager might add large window decorations and we'd still have part of the window be offscreen. I'm not sure how best to handle this...

xdg shell provides clients with the configure_bounds event, which should be used to decide their initial size. As long as the client requests decorations with the initial commit, it also takes server side decorations into account.

Compositors forcing apps to fit on the screen is more of a workaround that some but not all compositors apply.

[slouken]

@Kontrabant, do you want to take a look at adding support for that? I think the desired behavior is that the initial window creation of resizable windows would have the client area fit on the screen.

[ell1e]

I'm pretty sure GTK+ is affected as well since e.g. minigalaxy as a GTK+ application has the same issue, so if this is a toolkit responsibility then it seems like commonly the toolkits currently don't handle this well. Perhaps that info helps with deciding on where this is best solved. Feel free to weigh in on the KDE bugtracker if needed. (Sorry for the relatively uninformed comment, I hope this is helpful.)

[Kontrabant]

@Kontrabant, do you want to take a look at adding support for that? I think the desired behavior is that the initial window creation of resizable windows would have the client area fit on the screen.

Yep, it's very simple on the xdg-toplevel path. Libdecor is the annoying part since it has to be plumbed through the library as well.

[Kontrabant]

Done for the xdg_toplevel path in SDL 2 and 3.

[ell1e]

For what it's worth, it was brought up here on the GTK+ issue tracker that such a bounds restriction might often be considered undesirable behavior if applied during a manual resize, rather than only when the window is initially created. I assume that the SDL2 fix works like that, but just in case it doesn't, I wanted to leave this note here.

[Kontrabant]

We only apply the bounds when the window is being mapped, since on Wayland, we don't actually know where the mapped window will be. Beyond that, we don't interfere.