Borderless window, custom decoration and weird offset of the top left corner of the window

[flowCRANE]

I published a demo of my engine, as a showcase of a custom decoration, implemented manually in a window with the SDL_WINDOW_BORDERLESS style. All elements of this custom decoration are handled and rendered manually, as virtual elements inside the window client (the decoration is not rendered in non-client areas, i.e. it does not override WM_NCPAINT).

Here is the compiled demo, for x86-64: WtNC — decoration.zip

My engine doesn't use the system metrics at all, it doesn't base on the system decoration sizes, but on its own. The upper left corner of my decoration is always at point 0,0. The window of this demo after launch should look like this:

One of my testers reported to me that the window is displayed incorrectly and looks like this:

Blue area is the desktop background. My decoration is shifted 8px to the right and 31px down, and is cut off by 8px on the right and 31px at the bottom. I recognize these offsets — 8px is the default window border width used by the system to show the resize cursor and allow the user to resize the window with the mouse, while 31px is the default height of the window title bar in the case of the system decoration.

I suspect that despite using a borderless window, SDL uses the system metrics and that's why the window content is shifted and clipped (the window size is correct, but the window client area is shifted). Especially since my buddy reported to me that the engine sees the system cursor shifted by these offsets, i.e. e.g. the buttons on the window title bar highlight relative to the position of the system cursor in the window, with added offsets in the sizes of these black bars.

[Kontrabant]

Do you have more info on how to reproduce this (Windows version, video drivers, any particular settings changed, etc...)? My stock Win 10 and 11 test machines don't exhibit this issue with your example.

[flowCRANE]

Not yet, but I asked for more information. I'll let you know as soon as I find out anything.

[flowCRANE]

I already know a bit, I got a video recorded with a smartphone (unfortunately the smartphone automatically cropped the video, for some reason). Here is the link to the video:

https://drive.google.com/file/d/1Le1dlQ9cIgJVYQ8iiEEDQUa6VlsPygOA/view?usp=sharing

As for this user's computer, it has Windows 10, all updates installed, and has not changed the settings for interface and text scaling (they are at the default 100%). The problem with this demo is that it is 100% reproducible — the window in this demo is glitched every time. Interestingly, my buddy tested this demo on another computer, with identical parameters and settings, and this problem does not occur there (both devices used for testing are company hardware). So this problem occurs only with his computer.

From what you can see in the recording, the window has margins in the size of the system decoration, despite using a borderless window. The movement of the cursor over these black bars is registered by the engine, so the coordinates of the cursor in the window are correct, the hit-test callback also works correctly and allows moving and changing the size of the window. The engine also reacts correctly to the change of window size and recalculates the areas of all decoration elements. The only problem that exists is the shifted canvas of the window client.

These additional bars also exist in the maximized window. Maximization is handled in the standard way — clicking the button in the title bar simply calls the SDL_MaximizeWindow function, and clicking again calls the SDL_RestoreWindow function.

If anything, the engine uses the OpenGL driver and a standard 2D renderer. The renderer is created using the SDL_CreateRenderer function, with opengl as the renderer name in the second parameter. Renderer and all back buffer textures are created correctly, there are no errors in the logs.

If you need more information, write what is needed, and I will ask about everything. If necessary, I can modify this demo so that it logs any necessary information in the console (e.g. data provided by SDL events). So if you need to know something, write what it is, and I will add the appropriate logging code to the demo and we will test it.

[Kontrabant]

As far as I can tell, SDL is doing everything correctly, as recommended by MSDN: SetWindowPos() is called with SWP_FRAMECHANGED after creating the window to signal a client-size recalculation, and WM_NCCALCSIZE is handled and returns 0, which tells Windows that the client area extends from edge to edge.

Do both systems that it was tested on have the same GPU vendor and version of the video drivers installed? That's the only thing I can think of that could possibly cause it to fail on one and work on the other, everything else being identical.

[flowCRANE]

Ok, a friend gave me some information — this computer is a Lenovo ThinkPad W541 laptop and he wrote to me that all system updates are installed (via Windows Update, without unnecessary delay). Here are some screenshots:

Do both systems that it was tested on have the same GPU vendor and version of the video drivers installed?

No, it turned out that the two computers he was testing my demo on were two different laptops. He forgot that his buddy (in the company) had upgraded the hardware some time ago. So the problem only affects his Lenovo Thinkpad W541, but this bug is 100% reproducible on his laptop.

I don't know if this information is at all helpful to you, or if anything can be done with it since, as you said, SDL is programmed correctly. I didn't find any bugs in the engine code either, so I don't know if it's worth spending time on it.

[Kontrabant]

Closing this as the issue seems to be confined to one very old laptop for indeterminate reasons, and can't seem to be replicated anywhere else. Feel free to reopen this later if you have some new info on just what is causing it to break only on that specific machine.