[x11,sdl2] SDL_RecreateWindow at wrong position about sdl HOT 6 OPEN

What is happening here is that SDL adjusts the window position to report the origin of the content area, and when the window is recreated after already being mapped, it is being placed at the origin of the previous content location, and is then offset again by the title bar height. The solution is to subtract the old left and top border widths from the window position when recreating the window, but this will need to be tested against Win and Mac as well to ensure that nothing breaks.

from sdl.

It looks like it's not the title bar at work here, the window manager is moving windows down below the status bar at the top of the desktop.

I'd like to revisit setting the OPENGL flag by default so that windows don't need to be recreated when the renderer is instantiated.

from sdl.

I'd like to revisit setting the OPENGL flag by default so that windows don't need to be recreated when the renderer is instantiated.

Never mind, I forgot how complex setting up the OpenGL context and visual is, and the window attributes are highly dependent on the renderer's needs.

from sdl.

@akallabeth, a good workaround is to create the window hidden and then show it after creating the renderer.

from sdl.

It looks like it's not the title bar at work here, the window manager is moving windows down below the status bar at the top of the desktop.

To elaborate a bit, usually applications will create a window and immediately create a renderer, so the window is recreated before the window manager actually maps anything onto the desktop, and the coordinates used for recreating the window are the original ones passed at window creation time.

If the application creates a window and doesn't immediately create a renderer, however, the window can end up being mapped onto the desktop and sent a moved event, which sets the current window coordinates to reflect the window content area offset by the desktop toolbar and window decorations. If the window is recreated after this happens, the current origin of the content area, adjusted for any desktop toolbars and window decorations, will be used as the origin for recreating the window, and the window manager can then push the content area down again by the height of the window decorations so that the origin of the window, including decorations, is at the requested position. This can be replicated in the tests by adding SDL_PumpEvents() between window and renderer creation in the test apps.

In the case of FreeRDP, it looks like they are initially creating a window, then calling SDL_GetWindowSurface() at a later time, which implicitly creates an OpenGL backing texture for output that requires window recreation if the OpenGL flag isn't present, so the above is likely what is happening.

from sdl.

So I can reproduce this here on GNOME with testsprite, before dc7baa4.

In this case, the window is created and shown, the window manager immediately offsets the window Y position by the height of the status bar (not the window title bar), and then the renderer is created, which recreates the window at that new position, and the window manager offsets that again. There is no explicit pump events between the window creation and the renderer creation in this case.

from sdl.