search

fork-dev / TrackerWin

Bug and issue tracker for Fork for Windows
459 stars 10 forks source link

[Bug] Rendering issues in maximized mode (Windows 10) #777

Closed ma-bjo closed 3 years ago

ma-bjo commented 4 years ago

The Fork GUI gets cropped when the window is maximized on Windows 10. It looks like 3 pixels are missing along each border. For example, the '+' button and the scrollbar are missing some pixels to the right. The same is also true if you get a horizontal scrollbar along the bottom edge.

This is how it looks in normal mode, when things are fine: FormNormal

This is how it looks when the window is maximized, where the button and scroll bar are partly cropped. (This gets more evident on a real screen where the controls are next to the black edge. In this reported issue the background is white, which makes it look less cropped.) ForkMaximized

I also get some strange rendering artifacts when moving the window between screens in a multi-monitor setup, which could be related to this. If I have Fork maximized on my right monitor, and then move it to the left monitor by pressing Shift + WinButton + Left Arrow on the keyboard, I get an 8 pixel narrow band rendered along the left edge of the right monitor. Minimizing Fork and restoring it brings things back to normal.

I am using Fork 1.49.1.0 on Windows 10 1909.

vitalyster commented 4 years ago

Duplicate of #63

ma-bjo commented 4 years ago

Duplicate of #63

I don't think it is the same issue at all, #63 is about fonts being blurry, but this is a clipping issue of the entire GUI along the Windows edges.

DanPristupov commented 4 years ago

It's not the same issue.

@ma-bjo on my computer even the Windows Explorer window gets clipped in fullscreen. I'll show a screenshot in a few minutes.

DanPristupov commented 4 years ago

Notice a few pixels below the active icon:

Screen Shot 2020-05-29 at 11 01 45 Screen Shot 2020-05-29 at 11 03 01

Notice space around the left folder icon:

Screen Shot 2020-05-29 at 11 02 10 Screen Shot 2020-05-29 at 11 02 27

I'm not sure what's going on there, but even native applications are clipped in full screen.

SylwesterZarebski commented 4 years ago

Dan: What You see is 1px or 2px window border, which is hidden/removed on maximized windows. This issue mentions about cutting more than usual window border.

ma-bjo commented 4 years ago

Exactly. In Windows Explorer I think Microsoft has made a conscious decision to narrow their internal borders around the buttons somewhat in maximized mode, but if you look at the scrollbar to the right of the window it still has the exact same width and is not clipped. In Fork there are parts of it that are gone.

You should always restrict your controls and custom painting to the client area of the window, and typically to don't have to do anything for this to work correctly. Could it be that you have made assumptions about the border thickness and do layout based on the windows entire size (both client and non-client areas) instead of just using the client size?

Otiel commented 4 years ago

I concur with this issue. Windows Explorer has indeed internal borders smaller in maximized mode but this is not the case with most others applications, and it shouldn't be with Fork.

This has the consequence to make the scrollbar hard to grasp due to its smaller width. And several users have already complained that the scrollbar is not wide enough (see https://github.com/ForkIssues/TrackerWin/issues/471#issuecomment-593489561).

I also get some strange rendering artifacts when moving the window between screens in a multi-monitor setup, which could be related to this. If I have Fork maximized on my right monitor, and then move it to the left monitor by pressing Shift + WinButton + Left Arrow on the keyboard, I get an 8 pixel narrow band rendered along the left edge of the right monitor. Minimizing Fork and restoring it brings things back to normal.

I observe the same behavior, reported in #58.

DanPristupov commented 4 years ago

In the latest update we reworked the window layout completely. Could you check if there's any difference in 1.50?

ma-bjo commented 4 years ago

Yes, there is a difference, but unfortunately to something that is more broken. When I maximize the window on my left screen now, I always get a small part of it on the next monitor, and it does not go away anymore. Part of the scrollbar is on the wrong screen, so the result is still a clipped scrollbar.

I realize that you have tried to handle the window a bit special in order to be able to get rid of the normal window title. The borders are not following the theme entirely correct, and the resizing is not done in the drop shadow part as other windows do. I would very much prefer if you just had a normal window with normal border, it is not worth the quirks just to be able to utilize the few pixels that are occupied by the window header imho.

Otiel commented 4 years ago

Looks like there are still a few missing pixels:

image

SylwesterZarebski commented 4 years ago

All edges (top, bottom, left and right) has some cut pixels, only it is most noticeable on right one. I'm now on 4K 150% and confirm above behaviour.

SylwesterZarebski commented 4 years ago

PS. Could this be related? https://stackoverflow.com/questions/36725769/wpf-windowchrome-edges-of-maximized-window-are-out-of-the-screen

SylwesterZarebski commented 4 years ago

I just read this https://github.com/dotnet/wpf/issues/2242#issuecomment-561036653 and it is not very reassuring...

DanPristupov commented 4 years ago

Hi,

We made a build with many DPI-related changes. Could you try it and tell if you can see improvements?

The new version is available here as a zip archive (https://cdn.fork.dev/prerelease/Fork-1.50.5.zip). You need to extract it somewhere and run fork.exe.

Otiel commented 4 years ago

Looks to me that the missing pixels are back in 1.50.5.0. Good job. 👍

ma-bjo commented 4 years ago

Definitely an improvement! I no longer see any cropping or parts on the next screen as we saw in 1.50.0. There are however intermittent problems when moving the window from screen to screen or from maximized to half screen by use of the Win + Arrow buttons. I can reproduce two problems:

  1. Have Fork maximized on the right screen, and move it to the left screen using Win + Shift + Left arrow. This leaves a column a few pixels wide on the left part of the right monitor.
  2. Have Fork maximized on any screen, and press Win + Left arrow to make it occupy the left halv only. This places the window a bit outside the screen, which clips part of the top and left edge. Clearly visible in that the File meny comes very close to the screen edge.

Both these problems are much more minor compared to having part of the window spilling onto the next screen, so definitely worth including in a release even if those minor issues isn't fixed.

Otiel commented 4 years ago
  1. Have Fork maximized on the right screen, and move it to the left screen using Win + Shift + Left arrow. This leaves a column a few pixels wide on the left part of the right monitor.

58

Otiel commented 4 years ago
  1. Have Fork maximized on any screen, and press Win + Left arrow to make it occupy the left halv only. This places the window a bit outside the screen, which clips part of the top and left edge. Clearly visible in that the File meny comes very close to the screen edge.

I have this issue with all applications, when anchoring from a maximized window. It also clips the bottom of the window. This is a Windows bug, not Fork.

You have to hit WinLeft a second time for the window to be anchored correctly. Or perform the anchor from a non-maximized window.

SylwesterZarebski commented 4 years ago

I suppose it is perfect now, thanks a lot!