Preserve game UI scale on small screen sizes

[frenzibyte]

• Closes UI scale on iOS is too small by default #7012
• Does not (close) UI scale on Android is too small by default #31080 yet, see Preserve game UI scale on small screen sizes #31083 (comment)

As it turns out, SDL provides sane window size dimensions for iPhones, e.g. 852x393 on iPhone 16. We can use that information to construct an algorithm at a ScalingContainer level which ensures the game does not descale on small window sizes (inspired by previous discussions on the matter, mainly #21335 (comment)).

Preview on mobile:

[HOWZ1T]

A easy to digest PR 🙂
The fix to scaling would be great for small mobile devices! 🚀

The tests failing should be addressed and the hard-coded base_target_draw_size would ideally be configurable and not hard-coded at this level. However, depending on why this is, it may be more or less feasible.

[Joehuu]

Android seems to be giving resolutions scaled by DPI (also tested/seen on emulator):
On Pixel 6a:

[frenzibyte]

Well that shows that this cannot fix the Android issue without SDL providing a pre-scaled window resolution for host.Window.Size. According to Android, they define this as density-independent pixels (dp) and pixels are converted to dp by the inverse of the factor of dpi / 160. The Pixel 6a above has a scaling factor of ~2.68125 (429 / 160), converting the screen resolution mentioned above to dp form yields 895x403, roughly equal to the window size on an iPhone 16. cc @Susko3 in case interested, host.Window.Size is expected to return screen size in density-independent pixels but it returns it post-scale (i.e. host.Window.Scale is incorrectly equal to 1 probably).

[Susko3]

Window.Scale is using (the equivalent of) https://wiki.libsdl.org/SDL3/SDL_GetWindowPixelDensity, this is always 1.0f on android and windows, while differing on apple platforms. The pixel size is just an internal scaling factor when converting from physical pixels to "desktop coordinate space" positions.

This PR should actually be using https://wiki.libsdl.org/SDL3/SDL_GetWindowDisplayScale, which reports correct values on windows (haven't yet tested android): 200% display scale will yield 2.0f.

Could you update your code to use Window.ClientSize, scaling it by Window.Scale? This way, it can be easily updated to use SDL display scale once we implement this in framework (probably as IWindow.DisplayScale).

[frenzibyte]

I would hope we use the seemingly new API you mentioned directly on the Scale property inside the window class, and Size would reflect on that. Is that incorrect approach? Does SDL not include the pixel density in that API?

[Susko3]

I would hope we use the seemingly new API you mentioned directly on the Scale property inside the window class, and Size would reflect on that. Is that incorrect approach?

That would break most existing usages of Scale.

Does SDL not include the pixel density in that API?

Display scale and pixel density are orthogonal concepts. Depending on the context, it makes sense to apply one or the other.

[frenzibyte]

Looks like Android does indeed return the pixel density through the API you suggested: https://github.com/libsdl-org/SDL/blob/6cc9ce183d904489bf8e33e26b91d6012667e1b0/src/video/android/SDL_androidvideo.c#L181