Don't disable this functionality when defining SDL_LEAN_AND_MEAN, but if you need to, you can define SDL_DISABLE_STB if you want to compile this out.
Fixes https://github.com/libsdl-org/SDL/issues/15139
This Visual Studio 2019 compiler wrongly emits a warning.
test\testvulkan.c(271): error C2220: the following warning is treated as an error
test\testvulkan.c(271): warning C4090: 'function': different 'const' qualifiers
test\testvulkan.c(286): warning C4090: 'function': different 'const' qualifiers
Wayland is sometimes at-odds with clients that want to enforce an aspect ratio or min/max window size, as certain window states have dimensions that either must be obeyed (maximized), or will give terrible results if they aren't (tiled). Use a viewport and a masking subsurface to handle cases where surfaces are unable to match the exact window size.
The changes made to accommodate this also catches some additional windowing related edge-cases, simplifies synchronization, and prevents commits before a buffer has been attached to the surface.
We have an implementation that uses 128-bit math and one that handles large values without it (thanks @jessechounard and @rabbit-ecl!)
Fixes https://github.com/libsdl-org/SDL/issues/15042
V4L2 is able to advertise that a video device is able to display any frame
interval within a continuous range. SDL does not allow advertising this and
only exposes discrete frame intervals. To work around this, SDL attempted to
generate a subset of the range with a fixed interval. Unfortunately, the way
this was accomplish is inherently broken and led to attempting to allocate a
very large number of formats per resolution and colorspace. With the Magewell
Pro Capture HDMI, which can expose FRMSIZE_TYPE_CONTINUOUS as well, this can
expose a truly astronomical number of formats, exceeding 1 PB of RAM. This will
lead to an OOM kill for any process that tries to initialize the camera
subsystem.
This patch just tests to see if some common frame rates are within the
contiuous range and expose those. SDL still does not handle
FRMSIZE_TYPE_CONTINUOUS in a graceful way so it still uses over a gigabyte of
RAM for each possible combination of sizes, but with this patch it no longer
leads to an OOM kill. The API will need amending for proper support for both
continuous frame sizes and frame intervals.
