The preferred Pipewire path requires both devices being available, and that a sufficiently recent underlying core version is running on the host system. These criteria were being checked separately, which required two separate instances of enumerating the Pipewire registry, which is a fairly heavy operation. Move the version info callback to the main hotplug thread to avoid enumerating the registry twice, and check for both the version and required devices at the same time on the preferred path.
Currently, all SDL_Surfaces with an indexed pixel format have an
associated SDL_Palette. This palette either consists of entirely the
colour black, or -- in the special case of 1-bit surfaces, black and
white.
When an indexed surface is blitted to another indexed surface, a 'map'
is generated from the source surface's palette to the destination
surfaces palette, in order to preserve the look of the image if the
palettes differ.
However, in most cases, applications will want to blit the raw index
values, rather than translate to make the colours as similar as
possible. For instance, the destination surface's palette may have been
modified to fade the screen out.
This change allows an indexed surface to have no associated palette. If
either the source or destination surface of a blit do not have a
palette, then the raw indices are copied (assuming both have an indexed
format).
This mimics better what happens with most other APIs (such as
DirectDraw), where most users do not set a palette on any surface but
the screen, whose palette is implicitly used for the whole application.
Turns out that there isn't a strong OpenGL naming convention for "Delete" ...
WGL offers "wglDeleteContext" but the GLX equivalent is "glxDestroyContext"
and then EGL sealed the deal by going with Destroy as well! Since it matches
SDL3 naming conventions (Create/Destroy), we're renaming it.
Fixes#10197.
The SDL_Surface rework in #10201 adds some extra checks that the pixel
format enum matches the SDL_PixelFormatDetails struct, which is largely
filled in with values from SDL_GetMasksForPixelFormat().
However, there are a few cases where these do not match:
- Indexed 1-, 2-, and 4-bit formats encode a bytes_per_pixel of 0, but
SDL_GetMasksForPixelFormat() gives a value of 1.
- Packed formats, like SDL_PIXELFORMAT_XRGB8888 encode a bits_per_pixel
of the number of used bits (24), but SDL_GetMasksForPixelFormat()
includes the padding byte, giving a total of 32.
We could change the encoding of these in the enum, or change what we store
in the details struct to match, but I suspect we'd either break something
that relies on it, or lose some (_maybe_ useful) information. In the meantime,
this gets the tests working again.
Signed-off-by: David Gow <david@ingeniumdigital.com>
SDL_Surface has been simplified and internal details are no longer in the public structure.
The `format` member of SDL_Surface is now an enumerated pixel format value. You can get the full details of the pixel format by calling `SDL_GetPixelFormatDetails(surface->format)`. You can get the palette associated with the surface by calling SDL_GetSurfacePalette(). You can get the clip rectangle by calling SDL_GetSurfaceClipRect().
SDL_PixelFormat has been renamed SDL_PixelFormatDetails and just describes the pixel format, it does not include a palette for indexed pixel types.
SDL_PixelFormatEnum has been renamed SDL_PixelFormat and is used instead of Uint32 for API functions that refer to pixel format by enumerated value.
SDL_MapRGB(), SDL_MapRGBA(), SDL_GetRGB(), and SDL_GetRGBA() take an optional palette parameter for indexed color lookups.
Sam Lantinga
Ethan Lee
Frank Praznik
Ozkan Sezer
Anonymous Maarten
Giovanni Petrantoni
Substring
Ryan C. Gordon
David Gow
Brick
Isaac Aronson