In theory this is illegal, but legit wavefiles in the field do it, and
it's easy to bump it to 1 for general purposes.
Formats with more specific alignment requirements already check for them
separately.
Fixes#7714.
First one to load and have the necessary symbol is the one we accept,
if any. Once we accept one, we won't try loading others.
Fixes#7613.
(cherry picked from commit 32999798e0)
We have gotten feedback that abstracting the coordinate system based on the display scale is unexpected and it is difficult to adapt existing applications to the proposed API.
The new approach is to provide the coordinate systems that people expect, but provide additional information that will help applications properly handle high DPI situations.
The concepts needed for high DPI support are documented in README-highdpi.md. An example of automatically adapting the content to display scale changes can be found in SDL_test_common.c, where auto_scale_content is checked.
Also, the SDL_WINDOW_ALLOW_HIGHDPI window flag has been replaced by the SDL_HINT_VIDEO_ENABLE_HIGH_PIXEL_DENSITY hint.
Fixes https://github.com/libsdl-org/SDL/issues/7709
sdl12-compat can get into a state where a color-keyed surface is
marked for blending, but wants to blend with full alpha (which
is the same as _not_ blending), so rather than fail to find a
blitter in that case, it just selects the colorkey blitter.
Reference https://github.com/libsdl-org/sdl12-compat/issues/233
(cherry picked from commit 0eea92c8fc)
It turns out that screen coordinates were confusing people, thinking that meant pixels, when instead they are virtual coordinates; device independent units defined as pixels scaled by the display scale. We'll use the term "points" for this going forward, to reduce confusion.
This was only including the resampling buffer needs if it was larger
the other allocation needs, but it needs to be included unconditionally.
For safety's sake, we also make sure the pre-resample buffer doesn't risk
overflow, too, but this might not be necessary in practice.
Re-writes the clipboard data handling in wayland to an on demand
solution where callbacks are provided to generate/provide the clipboard
data when requested by the OS.
Wayland doesn't support getting the true global cursor position, but it can be faked well enough for what most applications use it for: querying the global cursor coordinates and transforming them to the window-relative coordinates manually.
The global position is derived by taking the cursor position relative to the toplevel window, and offsetting it by the origin of the output the window is currently considered to be on. The cursor position and button state when the cursor is outside an application window are unknown, but this gives 'correct' coordinates when the window has focus, which is good enough for most applications.
Before, as ConvertAudio might have expanded data in-place temporarily during
its work, this could blow up. Now if there's a chance of that, it'll
work out of an internal buffer and copy the final results to the output
buffer.
If the output format can handle the temporary expansion, we write directly
to the output buffer without the extra copy.
Fixes#7668.
Otherwise, a CoreAudio thread lingers forever, and coreaudiod eats CPU
until the SDL process terminates.
Fixes#7689.
(cherry picked from commit 86786ed544)
If the popup is positioned such that it requires correction on both the x and y axes, it will be aligned with parent only at the window corners, which is neither overlapping nor adjacent. In this case, nudge the window plus or minus one screen unit on the x axis so it is properly adjacent to the parent and within spec guidelines.
An in-place swizzle mutation was erroneously inside of a loop, which
caused each consecutive 4-pixel vector to alternate between correct and
incorrect endianness.
The bug was introduced in 715e070d29.
Thanks to RobbieAB for reporting the bug.
Fixes https://github.com/libsdl-org/SDL/issues/3428
Sam Lantinga