To reproduce:
* GNOME 49 in Wayland mode
* Intel integrated GPU with Mesa, if it matters
* either:
  * libsdl3 3.2.28+ds-2 (defaults to native Wayland video)
  * sdl2-compat 2.32.60
* or: classic SDL 2.32.10+dfsg-6 with `SDL_VIDEODRIVER=wayland` in the
  environment
* run the game

Expected result: A "Select your Profile" screen

Actual result with Wayland: A black window. If I press Escape, I get
what appears to be the expected window on every 2nd frame, and a black
screen on the remaining frames.

Workaround: Force use of X11 and the game seems to work normally (I
haven't tested actual gameplay, I'm just doing a quick skim through SDL
games in Debian looking for regressions).

If the root cause can't be found, a good way to enforce the workaround
would be to add something like

#ifdef SDL_VIDEO_DRIVER_X11
SDL_SetHintWithPriority(SDL_HINT_VIDEODRIVER, "x11", SDL_HINT_OVERRIDE);
#endif

at the beginning of main().

This will become more serious when we move to sdl2-compat as the
default, which I would like to do in early 2026.

    smcv

Control: forwarded -1 https://gitlab.com/domino-chain/domino-chain.gitlab.io/-/issues/20

This seems to be the same thing that was reported upstream as
<https://gitlab.com/domino-chain/domino-chain.gitlab.io/-/issues/20>.

See also <https://github.com/libsdl-org/sdl2-compat/issues/569> looking
at this from the SDL side.

     smcv

assuming that the backbuffer contents from each frame are preserved
after the frame is presented, but this is undefined behaviour in OpenGL
and Vulkan: with some platform/driver combinations it happens, but with
some it does not.

SDL's rendering API never guaranteed this either, but in practice it
usually worked in the past. Newer versions of sdl2-compat will work
around this by forcing use of SDL's software renderer for domino-chain,
which does have the backbuffer-preserving behaviour.

Reference: https://github.com/libsdl-org/sdl2-compat/commit/61789ee297b0dd0fae298fb4fd8c86afff933c08

     smcv