You can grab the build from github actions: Workflow runs · libsdl-org/SDL_image · GitHub. The latest workflows are failed, but only for some configurations.
Thank you for all the feedback!
The preview releases have been removed, and you should be targeting the latest SDL in GitHub for development.
We will create another preview release once the SDL 3.0 API is stable and we will be ABI compatible going forward at that point.
How is the API expected to stabilize for devices that have different dpi horizontally and vertically (and therefore different content scale for the two axes)?
1 Like
Ugh, that’s a thing?
Everything related to DPI scaling is painful enough as it is, what kind of idiot invents different scaling factors per axis?! Some people just wanna watch the world burn…
Yes, Win32 has GetDeviceCaps function, and by using LOGPIXELSX or LOGPIXELSY in a parameter it is possible to get horizontal or vertical dpi. I’ve already shown a screenshot of an example configuration with different dpi horizontally and vertically: Announcing the SDL 3.1.0 Preview Release - #18 by PiotrGrochowski . This is necessary to handle displays that have non-square pixels.
The legacy Win32 versions of DPI scaling (as in Windows NT 3.5 to NT 6.2 (up to Windows 8.0), as well as Windows 95 to ME) are not painful to use at all; all the positions and window dimensions are still in pixels; one of the simple ways for Win32 software to handle DPI scaling is to have multiple resources of varying resolutions, and use the horizontal and vertical dpi to pick the appropriate resource, and drawing it in the original pixel scale or integer scaling factor guarantees that the resource is pixel perfect. On Windows 8.1 and up and other platforms, DPI scaling is indeed more painful to use.
SDL has a concept of content scale (user specified) and pixel density (relationship between pixels and window coordinates). There’s no DPI support directly in the API, you just work with window coordinates and pixels. If you want to support devices that have non-square pixels, you should use platform-specific APIs to detect these and use the appropriate resolution resources to handle them, as you’ve shown below.
2 Likes
However, having different dpi horizontally and vertically implies different content scale horizontally and vertically, as 96dpi on Windows is equivalent to 100% content scale, therefore, a configuration of 96dpi horizontally and 120dpi vertically is equivalent to a 100% content scale horizontally and 125% content scale vertically. And relying on platform-specific APIs defeats the purpose of the API being cross-platform.
1 Like
Non-square pixels have been around since the dawn of digitised images, the very first digital-video standards for television used non-square pixels. Since many early computers were designed to feed a TV set as their display device they often inherited non-square pixels too.
Exactly square pixels are actually a relatively recent phenomenon, and although they’re convenient for graphics, designing a ‘flexible’ API around that assumption feels wrong. SDL ought to be the ideal ‘layer’ in which to introduce different horizontal and vertical scaling, when that is required.
There are 16/9 screens with different Y resolutions: 1920x1080 and 1920x1200. Logically, the pixels on one screen cannot be square.
1 Like
@slouken this is instigative news. The exercise release of SDL3.1.0 looks veritably promising with all these new features and advancements. I’m interested in exploring the reworked API for easier use and the support for HDR picture and Vulkan backend in the 2D rendering API.
Thank you to the development platoon and contributors for their hard work 
I’ve been using SDL2 for a few months now and I’m very excited for SDL3. Does SDL3 work with Emscripten? Thanks T