libsdl-org
no window on wayland
On wayland it shows no window, unless you call SDL_UpdateWindowSurface(win).. whereas on x11 this is a window. maybe not a bug ... (seen by @madebr)
#include <SDL3/SDL.h>
int main(int argc, char *argv[]) {
SDL_Window *win = SDL_CreateWindow(NULL, SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 640, 480, 0);
if (win == NULL) {
return -1;
}
while (1) {
SDL_Event event;
while (SDL_PollEvent(&event)) {
switch (event.type) {
case SDL_QUIT:
case SDL_KEYDOWN:
exit(1);
}
}
//SDL_Surface *scr = SDL_GetWindowSurface(win);
// SDL_UpdateWindowSurface(win);
}
SDL_DestroyWindow(win);
return 0;
}
Wayland needs you to render and pump the event loop or it fails like this.
Maybe we should consider either logging a warning or just drawing a black screen if this happens at startup?
CC @flibitijibibo
yes, maybe not a bug. just questioning ...
also, we notice it happened using:
if (SDL_CreateWindowAndRenderer(WIDTH, HEIGHT, 0, &g_window, &g_renderer) < 0) {
it had :
SDL_Surface *scr = SDL_GetWindowSurface(win);
SDL_UpdateWindowSurface(win);
but no SDL_RenderPresent()
( before https://github.com/libsdl-org/SDL_gesture/commit/8017c5dc3ebb94413fd57d0d212d1d996832a7c4 )
I would say PollEvents twice in a row without presenting is a red flag in general - we could come up with wacky schemes to try and make all SDL apps present quickly, but specifying that we present a surface only after calling a present function would be easier and also give us an excuse not to show uninitialized data on other video targets.
I guess the question is how hard is it to safely clear a window when we don't necessarily know what they're using to render, and if they are presenting without calling an SDL function, like they would with Vulkan.
If there's a way to just force it at startup without having to build up a GL context, call glClear and then tear down the context, I'm fine with that, and then they're on their own to draw something, but we won't get bug reports that a window didn't show up at all.
But if this is a giant hassle, let's just leave it alone.
The easiest way would be to attach an shm buffer to the surface and block until a presentation event occurs to show the window. There even exists a protocol for easily creating single pixel buffers for drawing blank surfaces in conjunction with a viewport. However, I don't know if there would be problem attaching a GL or Vulkan buffer to the surface afterwards, and you get into all kinds of cases where the window may be created hidden and a backbuffer is attached unbeknownst to SDL when it is shown and so on.
The proper way to do this would be with subsurfaces: the blank window surface is the parent and the application surface would be an async subsurface, but that starts to get messy, and subsurfaces are not bug-free across compositors (went down this road trying to do aspect-correct fullscreen, and eventually abandoned it as various desktops needed all kinds of hacks to work around bugs).
Either way, it complicates SDL's current "here's a surface, draw your stuff" model just to show a blank window in some edge cases. Basically:
if this is a giant hassle, let's just leave it alone.
