stride3d / stride3d/stride

Linux/X11 (compositing WM): any window change after device creation wedges the Vulkan presenter inside `CreateSwapChain` — fullscreen toggle, border removal, even a bare `SDL_SetWindowPosition`

Open
#3,320 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C#
Stars
7.8k
Forks
1.2k
Avg merge
2d 17h
Merged PRs (30d)
49

Description

Release Type: Official Release
Version: 4.3.0.2507
Platform(s): Linux, X11, compositing WM (repro on Cinnamon/Muffin); Windows/D3D11 unaffected

Describe the bug
Every post-device window mutation we tried permanently wedges or crashes the game. Live stacks
(two independent variants) pin the hang inside
SwapChainGraphicsPresenter.Present()CreateSwapChain()CreateBackBuffers(), never
returning, ~37% CPU spin. Variants reproduced in one evening, each attempted as the "safer"
fallback for the previous:

  1. GameWindow.IsFullscreen = true pre-load → device presents to a black screen forever.
  2. Stride borderless path pre-load (FullscreenIsBorderlessWindow + Position + SetSize) →
    window never mapped, Present() at 0 fps, WM kills the "unresponsive" app in ~20 s.
  3. Same borderless transition post-load → immediate segfault at the transition frame.
  4. Raw SDL_SetWindowFullscreen(FULLSCREEN_DESKTOP) after the loop was pumping → permanent
    wedge with the stack above.
  5. Minimal case — SDL_SetWindowBordered(false) + SDL_SetWindowPosition, no size or mode
    change
    (backbuffer already equaled the display) → same wedge, same stack.

To Reproduce
Code-only Linux game on X11 under a compositing WM; after the first frame, perform any of the
five variants above.

Expected behavior
Fullscreen/borderless transitions work, or fail recoverably.

Additional context
Suspected: the swapchain rebuild waits on in-flight presentation that never completes once the
surface is invalidated under a compositing WM. Working pattern (ships today, worth
documenting for code-only games):
construct a fully-shaped GameFormSDL before
Game.Run — border style, final size, final position — so Stride maps the window exactly once
in its final state and builds the swapchain exactly once. Verified on a four-monitor X11
desktop. One repro caveat: poke SDL only through the engine's Silk.NET binding — a raw
DllImport("SDL2") loads a second SDL with uninitialized state and returns garbage bounds.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the post-device window mutations on Linux/X11 with a compositing WM, then trace the reported path through SwapChainGraphicsPresenter.Present(), CreateSwapChain(), and CreateBackBuffers(). Compare the failing transitions with the pre-shaped GameFormSDL setup and verify the engine's Silk.NET SDL binding is used. Done means fullscreen or borderless changes either recover correctly or have a documented supported path.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp, linux
Domain
desktop-dev, game-dev, operating-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.