SDL2: direct3d batching causes strange issues on widescreen monitor

[ivan-mogilko]

According to the changelog, the "batching" mode was introduced in 2.0.10. In our project we were using a much newer version of SDL (started with 2.12 iirc, and 2.24 currently), and tbh I did never pay attention to these specifics. But recently I've been investigating a weird user's problem, and eventually found that it's related to this "batching" mode.

What happens is this: if the program starts in windowed mode, or fullscreen mode, both ways things look fine. If program is switched from fullscreen to windowed (or windowed -> fullscreen -> windowed), the window is never resized to a smaller size, instead it remains big covering almost whole desktop. But the game's image becomes aligned to a left edge, or top-left corner. Another thing that user noticed is that this "corrupt" window turns out to be "system topmost", other applications always stay below it, as if it kept a "topmost" flag from fullscreen mode.

Following are two videos recorded by user (he had to use a phone): https://www.dropbox.com/s/aez61e8ezm1em4q/sdl-direct3dbatching.zip?dl=0 (archive is 18mb but i may attach to this ticket instead if you think that's better)

User has a following system (note the ultra-widescreen monitor):

• Windows 10 Pro
• Monitor: LG 34" WL500 (ultra-widescreen)
• NVIDIA GeForce RTX 3070 video card
• Desktop Resolution: 2560 x 1080 x 74 hertz

SDL_CreateRenderer seem to create a "direct3d" by default when we do not request particular one, and enables "batching" by default too. If we request "direct3d" explicitly, then the batching is off by default. (Btw, this discrepancy puzzled me a alot while investigating the problem, i even had to look into the library code to find out what's going on, as I was not aware of how this setting works.)

We tested setting SDL_HINT_RENDER_BATCHING to 1 and then tried other renderers (software, opengl), but only direct3d was causing the problem.

So the issue in question happens only with "direct3d" renderer and with batching on.

---

I'd like to find out if it's a problem in SDL2, or we are doing something obviously wrong in our program.

Without too much extra details, what we do there is:

SDL_SetWindowFullscreen(window, 0);
SDL_SetWindowResizable(window, SDL_TRUE);

followed by:

SDL_SetWindowFullscreen(window, 0);
SDL_SetWindowSize(window, width, height);
CenterWindow
SDL_SetWindowResizable(window, SDL_TRUE);

where "CenterWindow" is using code posted in this comment, because SDL2 does not account for task bar when centering:

    SDL_Rect bounds;
    int w, h;
    int bx1, by1, bx2, by2;
    SDL_GetDisplayUsableBounds(SDL_GetWindowDisplayIndex(window), &bounds);
    SDL_GetWindowSize(window, &w, &h);
    SDL_GetWindowBordersSize(window, &by1, &bx1, &by2, &bx2);
    int x = bounds.x + bx1 + (bounds.w - (w + bx1 + bx2)) / 2;
    int y = bounds.y + by1 + (bounds.h - (h + by1 + by2)) / 2;
    SDL_SetWindowPosition(window, x, y);

As you may notice there's a certain repetition, where SDL_SetWindowFullscreen(window, 0); gets called twice eventually. This is an oversight in our code organization. But I cannot tell whether this may or not have anything to do with the issue.

[slouken]

We are scoping work for the SDL 3.2.0 release, so please let us know if this is a showstopper for you.

[ivan-mogilko]

We are scoping work for the SDL 3.2.0 release, so please let us know if this is a showstopper for you.

No, it's not, this problem was reported by a single user so far, and it's possible to work around.