SpriteBatch.End() occasional hang when mixing deferred and immediate modes on Linux OpenGL backend
On Linux (OpenGL backend) when using SpriteBatch in both Begin(SpriteSortMode.Deferred) and Begin(SpriteSortMode.Immediate) in the same game loop, occasionally the call to SpriteBatch.End() in the immediate‑mode block hangs (freezes) the game. Steps to reproduce:
On a Linux machine, target desktop GL version of MonoGame.
In your game loop, do something like:
spriteBatch.Begin(SpriteSortMode.Deferred, …); // draw some sprites spriteBatch.End(); spriteBatch.Begin(SpriteSortMode.Immediate, …); // draw some other sprites spriteBatch.End(); // may hang here
Run enough frames; occasionally the second End() will cause a freeze (no error, deadlock appears). Expected behavior: Both deferred and immediate modes should work interchangeably and never hang. Actual behavior: Surface hang in some cases (seems random) when mixing modes on Linux OpenGL. Additional info:
Doesn’t appear on Windows DirectX backend.
Might be related to how the rendering batch flushes and command buffer is handled in immediate mode on GL. Why this matters: Cross‑platform behaviour is a core promise; developers working on Linux get unexpected instability. Suggestion: Investigate OpenGL pipeline for immediate mode flush handling; ensure SpriteBatch.End always returns. Add logs or debug assert for command buffer states.
Might be related to how the rendering batch flushes and command buffer is handled in immediate mode on GL.
That shouldn't happen as per GL specs, so it might be a driver problem. There shouldn't be any overlap unless you're using threads and/or overlapped spritebatches.
What is your linux distro and what is your graphics driver/GL implementation?
That behavior sounds suspicious to me, I've never seen a GL implementation doing what you're describing.