Toggling Windowed to Fullscreen Glitch

[Enjay]

I'll raise a proper bug report for this if need be, but it might be system specific.

I noticed when playing with a WADSmooshed PK3 that the episode menu fell off the bottom of the screen ( https://forum.zdoom.org/viewtopic.php?f ... 64#p967264 ).

If I hit alt-enter to go to windowed mode, the menu was fine and when I hit alt-enter again to go back to full screen the menu went back to being too big in ZDoom and QZDoom.

In GZDoom, however, things don't go back to full screen properly. The windows task bar is still visible at the bottom of the screen. What's more, GZDoom is playing at a slightly smaller than normal resolution. My resolution is 1920x1200 and I took a screenshot just to see what would happen. The task bar wasn't captured but the screenshot was only 1920x1173. GZDoom is kind of effectively half back in full screen mode. The window borders have gone but the task bar remains. The GZDoom screen is big enough that I can see the bottom edge of the GZDoom window behind the task bar, but not all the way down, only about 1/3 of the way down and below that I can see my wallpaper.



GZDoom also "knows" it's in a lower resolution because all the menus are scaled a little bit smaller. If I quit and go back in to GZDoom, it runs in full screen as normal.

To be clear, this happens with or without WADSmoosh loaded.

Windows 10 64bit GTX1080 current driver.
Both today's git build of GZDoom and the official release.

[Rachael]

What version of Windows 10 are you running? I am running Anniversary (1607) and am not getting this problem. I have an otherwise similar (at least, by vendor, but my hardware is a bit older) system setup as you do.

EDIT: Nevermind, I got the issue when I ran fullscreen at my monitor's native resolution (same as my desktop). This does seem to be a bug, but not sure if with Windows or GZDoom.

[Enjay]

I'm also running Anniversary (1607) Windows 10 Pro 64 bit fully updated.

Edit: Just seen your edit.

[Rachael]

Unfortunately, I do not have enough experience in coding hardware OpenGL to look into this, and as far as I am aware Graf does not use Windows 10. So unless the problem is reproducible in Windows 8 this issue may not be fixed.

One question I do have though - if you run QZDoom with "+vid_used3d false" does the same issue occur?

[Graf Zahl]

This almost sounds like Windows is clamping the requested Window size to what it thinks is the largest available screen area.

[Enjay]

Just out of interest, I tried again with a couple of taskbar modifications. First I put the taskbar to the left of the screen and then I put it back to the bottom but switched on autohide. Neither of these made a difference. i.e. with the taskbar on the left, GZDoom came back at 1920x1173 (i.e. the bottom of the screen not covered) and the taskbar still visible on the left. With autohide on, I did the alt-tabbing with the bar not visible and GZDoom still came back with the bottom of the view not quite at the bottom of the screen.

So, basically, the task bar doesn't seem to be particularly relevant.

Is there any way for me to check what screen area windows thinks is available? Everything I've looked at (nVidia settings and so on) says 1920x1200.

[dpJudas]

This almost sounds like Windows is clamping the requested Window size to what it thinks is the largest available screen area.

It does do this. It even makes the window slightly smaller because it includes the nonclient area that used to contain a drop shadow in Windows 7 in the calculations.

Fixing it may be a matter of first removing the window decorations and then resize the window. I suspect it might be doing it the other way around today.

[MagicWazard]

Since there's already a thread created...I have this same issue in Windows 7, 64-bit.



This occurs from 2.2.0 onwards, into 2.3.1. This didn't occur before 2.2.0 (for example, 2.1.0 is fine).

I'll check Github in the next day or so to see if this has been formally reported there as well; if so, I'll put this info there too.

Here's the link to my MSinfo, since it's too large to attach:
https://www.dropbox.com/s/6aomy8ucs84k7 ... o.txt?dl=0

[Graf Zahl]

I finally managed to track this down.

This was caused by dpJudas's code to allow arbitrary window sizes. The old code had one really stupid property - it always assumed that a window of the requested size could be created - but that's not the case if the window is fullscreen - Windows subtracts the frame from the screen size for the client area. The original code never cared about this fact, and set the internal screen size to something larger than actually was available, and restored fullscreen to that size later. The current code actually calculates proper window sizes, but forgets to adjust for that when switching back to fullscreen. So the fullscreen window will always be the size of the last non-fullscreen window and not fill the screen.

And here's the problem: Since you can drag the window around, shrinking and expanding it at will, going back to fullscreen may induce an unwanted screen resolution change if I just switch to the next fitting fullscreen mode. To handle this properly more is needed - like maybe a major change of the video backend's fullscreen handling. I think the best I can do is force any weird sized window into desktop-resolution fullscreen instead of trying to match the window size as closely as possible.

[dpJudas]

There's a VideoWidth and VideoHeight property on all DFrameBuffer derived objects that holds the original targeted fullscreen video size. The problem can probably be solved by adding a rule comparing Width and Height to VideoWidth and VideoHegiht if IsFullscreen() returns true.