SDL3: Use SDL_CreateWindowWithProperties instead of SDL_CreateWindow

[RT2Code]

SDL3 added a new function SDL_CreateWindowWithProperties which allows specifying more options before the window is created compared to SDL_CreateWindow.

The issue I tried to fix is described here: #7989 (comment)

If you disable the NoDecoration flag and drag a window outside the main viewport, you can sometimes see the frame on the new window in the top left corner of the screen.

It kinda works. You can still sometimes see the frame, but it's smaller and less apparent than before. It's not perfect, but it's still an improvement, and it is semantically more correct because it allows the SDL to set each option as early as possible on each platform, which is desired to avoid some eventual transition breaking effects due to parameters changed after the window creation. It also makes the code easier to read imo.

[ocornut]

Can't we use SDL_WINDOW_HIDDEN and then call SDL_ShowWindow() afterwards?

While I agree that API ultimately may allow more features/flags, right now it seems more verbose for no particular added value.

[RT2Code]

I tried, if we create the window hidden, the "phantom window" seems to appear less often (it's hard to evaluate as this issue is kind of random anyway), but this doesn't fix it entirely.

I captured the issue to help you understand what I'm talking about:

Screen.Recording.2024-09-17.195208-1.mp4

And here's how it looks with SDL_CreateWindowWithProperties:

Screen.Recording.2024-09-17.195721-1.mp4

Anyway, this issue is pretty minor and this PR was more a suggestion than a real fix, so if you prefer the original SDL API, I think it can be closed. :)

[ocornut]

What you call the "phantom window" doesn't seem like a minor issue to me, it seems rather bad.
But I don't see it here on my Windows 10.

I don't understand why the issue would be any "random":

• passing SDL_WINDOW_HIDDEN to SDL_CreateWindow() shouldn't show it?
• then we are free to call SDL_SetWindowPosition() followed by SDL_ShowWindow().

If this doesn't work perfectly there is something that needs investigating, perhaps on SDL3 side?
My intuition is that SDL_WINDOW_HIDDEN is not correctly implemented?

[RT2Code]

By random, I mean that it's not consistent, at least visually speaking, it's not visible every time I drag a viewport outside the main window. I'd say it happens about half the time. I suppose that the window is being created in the top left corner and is, in a second step, moved to the requested position, even with SDL_CreateWindowWithProperties. I can still see it happen with SDL_WINDOW_HIDDEN, albeit less often.

I thought it was minor, but if you consider this a real issue, I'll spend more time investigating the cause and try to correct it tomorrow.

[RT2Code]

I checked the SDL3 sources, and SDL_CreateWindow is defined like this:

SDL_Window *SDL_CreateWindow(const char *title, int w, int h, SDL_WindowFlags flags)
{
    SDL_Window *window;
    SDL_PropertiesID props = SDL_CreateProperties();
    if (title && *title) {
        SDL_SetStringProperty(props, SDL_PROP_WINDOW_CREATE_TITLE_STRING, title);
    }
    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_WIDTH_NUMBER, w);
    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_HEIGHT_NUMBER, h);
    SDL_SetNumberProperty(props, SDL_PROP_WINDOW_CREATE_FLAGS_NUMBER, flags);
    window = SDL_CreateWindowWithProperties(props);
    SDL_DestroyProperties(props);
    return window;
}

It simply defines some properties and forwards the call to SDL_CreateWindowWithProperties, so there shouldn't be any difference in behavior between these functions. It made me realize that I forgot to define SDL_PROP_WINDOW_CREATE_WIDTH_NUMBER and SDL_PROP_WINDOW_CREATE_HEIGHT_NUMBER properties. That's why the issue is visually different with my changes: The window is created with a size of 1 pixel, so the visible frame is smaller. If I define those properties, there's no difference between both APIs.

But I wasn't able to find a fix for this issue yet. Hiding the window at creation seems to only reduce the occurrence. I suppose it's related to the SDL internal behavior because it doesn't happen with the win32 backend. I'll keep looking for a fix. I need to do more digging into the SDL code.