Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upWindow size not adjusted when dragging form high dpi to second monitor (windows 10) #275
Comments
|
|
Can't upload log files in the github issue tracker, hoping this works. Let me know if you need more info. On 18/08/2015 09:30, Maximus5 wrote:
12:10:15.002 ConEmu 150816[64] log 12:10:14.776 ConEmu 150816[64] log[1] |
|
Ok, that seems to have worked except for the screenshot, trying that here.
|
|
|
However, from your cropped logs I can see, that your system do not support "per-monitor-dpi". |
|
I am also experiencing this issue when dragging between a 4K high-DPI display and a regular-DPI display. Logs here. Screens look similar to what @HnLn posted. What's strange is that ConEmu's non-client area (the titlebar) becomes huge on the low-DPI screen. With every other app I've seen, the titlebar resizes to match the display DPI. Related: https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx |
|
Why do you report Microsoft problem here? Windows controls non-client area internally! |
|
Anyway, without screenshots and comments about expected window, TabBar and font sizes I can't say anything more. |
|
I don't think this is a Microsoft problem; rather, it appears to be a quirk in ConEmu's DPI awareness implementation. I would expect ConEmu to behave like Explorer: when you drag an Explorer window from a high-DPI screen to a low-DPI screen, the window resizes to match. See this video for an example: https://youtu.be/f3Gujt4cW9c (sorry for the garbage video of my monitors) In the video, the lower display is a high ~200 DPI display and the upper monitor is a regular ~96 DPI display. You can see that when you drag an Explorer window between displays with different DPIs:
ConEmu does complete step 4 (the text in the terminal is rendered at the current display DPI), but it does not complete step 3 -- the window retains its pixel diminsion on the low DPI screen, which results in a huge window. As a consequence of doing 4 but not 3, the row and column count of the terminal changes when you drag between screens. I'm not sure exactly what Explorer is doing that ConEmu isn't. |
|
It is Microsoft problem! You may enable Hide caption always, than ConEmu can control all areas of the window. Otherwise... again, this is Microsoft problem. Don't they have developers to emulate non-client area visual appearance? Seems like. But this is weird. Also, show screenshot of the main settings page. |
|
Hmm.. my apologies -- it appears you're correct. Looks like Explorer is drawing its own titlebars, so that's why it works as expected. It's absurd that the non-client area isn't automatically DPI scaled by the system. Even with ConEmu's Hide caption always, the window does not maintain its physical dimensions when dragging between monitors (ie step 3 from above). It would be nice if ConEmu resized its window pixel size on Settings screenshot: |
|
|
And I need LogFiles
|
|
Enabling "Treat font height as device units" does not really help -- it only makes the text bigger.
On high DPI display: On low DPI display: Size & pos: |
|
From https://msdn.microsoft.com/en-us/library/windows/desktop/dn280512(v=vs.85).aspx:
Looks like |
|
@daguej Of course I read msdn article. Suggested size is nice, but don't think that this size would fit your expectations. It's nice for browsers, perhaps, the applications which do not care about row/col dimensions. They just renders sites with flexible layouts. |
|
I've noticed the same thing - Here's Babun (top), cmd.exe (middle) and Cmder (bottom):
Edit: Disregard, it fixed itself after rebooting. |
|
Babun uses mintty, which is only system DPI aware. That means its window is using the less-than-ideal DWM raster scaling. Cmder uses ConEmu, so it suffers from this issue. Windows 10's conhost (the built in command prompt) is the only app I've seen that actually does scaling 100% right. Not only does it scale the contents of its windows, it also somehow scales the non-client area and system menu correctly! It does this for both the command prompt window and the options window. Everything draws at the correct DPI/physical size and looks perfect on high- and low-DPI screens. |
|
For completeness, I attach the pixel perfect screenshots of the both types of windows, low dpi and hi dpi: It is expected the text to be smaller of course, to follow the dpi settings. It is not expected the decoration to stay the same... |
|
I got a Surface Book lately and ran into the same problem with ConEmu (thanks for the great product). Searching around a little let me to the following article: https://blogs.technet.microsoft.com/askcore/2016/08/16/display-scaling-changes-for-the-windows-10-anniversary-update/ Interesting part is about the Non Client Area Scaling. As I understand the article there is now new API in Windows 10 Anniversary Update that will handle NCA scaling. |
|
Ah -- very exciting! This means ConEmu can now render windows correctly on different DPI displays.
|
|
@Maximus5 I started hacking on this issue in a branch. I have However, after dragging, the non-client metrics of the window change (since the titlebar and window borders are now different pixel sizes). This results in things being positioned incorrectly since it does not appear to account for the new metrics. For example, the window on the main high DPI display: When dragged to a low DPI display:
Notice that on the high DPI display, the tab bar is 60px from the top of the window since the titlebar is 60px tall. However, on the low DPI display, the tab bar is still 60px from the top, even though the titlebar is now only 30px tall. Additionally, the tab bar should resize to render at the new DPI. I spent a little time fiddling around, but I couldn't figure out how to get the window to re-render at the new DPI. Any ideas how to make that happen? |
|
Thanks for the comments on that commit. I've made some adjustments and opened a PR (#1014) so we can do proper review. |
|
Issues that I found (moving window from 192 DPI to 96 DPI):
|
|
Windows 10 Creators Update has new feature Per-monitor DPI awareness V2 https://blogs.windows.com/buildingapps/2017/04/04/high-dpi-scaling-improvements-desktop-applications-windows-10-creators-update/#5BTseFmuW5vB2lgJ.97 |
|
Hi, I can confirm, that this works just fine in Windows 10 / Creators Update. |
|
@SidShetye That option does fix the problem with Settings Dialog and Window Caption. However, on my high DPI monitor, the text on screen gets blurry (whereas it is not on the low-DPI monitor). *Low DPI:
Pretty sure Windows is just 'scaling' the ConEmu bitmap (before rending to screen) up by 250%, leading to aliasing artifacts. |
|
Watching this thread and imagining someone like me might come along... I wanted to comment that setting the windows "override" actually creates UI artifacts for me, but the "Hide captions always" is a real improvement. Thanks for that tip, @Maximus5 ! |
|
@SidShetye, @m4dc4p: |
|
After downloading 171109 the behavior has changed, now in High DPI monitor it looks good, but it meses when launching into or moving to a low dpi monitor. With two monitors attached (Surface builtin one as high dpi): Launching on low dpi monitor (black border on top glitch): Resizing on low dpi monitor (look for artifacts, duplicated text): Settings on low dpi monitor: Moving to high dpi monitor (looks good): Resizing on high dpi monitor (looks good): Settings on high dpi monitor (looks good): At least now it's consistent, moving back and forth between monitors produces the same results, the high dpi one is always the monitor that looks good, and the artifacts and sizing problems appear on the low dpi one. |
|
+1; 171109 feels like a regression from my perspective -- low-DPI displays are sometimes unusable with the extra unpainted border leading to visual glitches over time. This also affects the tab-bar (not shown above): |
|
I'm experiencing what may be a variant of this issue. I have a laptop with an external monitor (primary) attached via a dock. They're both the same resolution (1920x1080) but the external monitor is physically larger. The laptop screen is set to 125% scaling in Windows and the external monitor is set to 100%. When I drag a ConEmu window from the external monitor to the laptop screen, the fonts scale up but the window stays the same size. This results in the window being too small to display the full width of the console. If I type a really long command, the text goes past the right border of the window before eventually wrapping to the next line. I.e. The underlying console buffer is 120x30 but the window is only showing 98x24. I'm using Conemu v180506 preview on WIndows 10. These are my font settings: These are my size & pos settings: I do not have the caption bar hidden. This is an example of the window on the external monitor: And the same window dragged to the laptop screen: |
|
Compared to a normal Powershell console window: (open the images in separate tabs to see the size change, Github is resizing them to fit the same space on this page) External monitor: Laptop screen: |
|
Here's an example from my computer when dragging between two monitors. (Repros on 180422 and 180617) |
|
@theficus 180422 is old build. But to be sure, what do you want to demonstrate? I see scrollbar cropping but it doesn't relate to that issue directly. Anyway, do you have scrollbar always ON? |
|
@Maximus5 I just installed the latest build (180617) and the same issue occurs. It's not clear in the screenshot, but the window becomes sized significantly smaller when moved from monitor A to monitor B (and significantly larger when doing the reverse). I didn't even notice the scrollbar clipping until now but yes, it's always on. |
|
Ok, here's a better demonstration. The window on the left and the window on the right should be the same size but as you can see they are significantly different between the two monitors. If I were to drag the window from the right monitor to the left one, it will be the size shown in the ConEmu window on the left. If I drag the window from the left to the right, it will be the enlarged size on the right. Left monitor is at 200% scale, right monitor is at 100% scale.
|
The solution works for me. |
* upstream/master: (29 commits) 200604 release files 200604 Chocolatey and Nuget l10n: translations were updated Update build system to VS2019 Maximus5gh-275: Fix cropped scrollbar on high-dpi second monitor. Fix wrong tab- and statusbar placement after dpi change. adjuist order of redraw when DPI changes redraw controls when DPI changes Use `swap` calls on lvalues. Use clear instead of swap Use clear instead of swap Fix variable initialization. Avoid uninitialized values. Fix cross initialization Fix cross initialization Fix cross initialization Fix cross initialization Fix cross initialization Fix cross initialization Create FUNDING.yml ...
|
Sadly, this issue is not actually 100% fixed. I can confirm that in the latest version (200615), the window size issue has not been addressed. (Happily, I think all other aspects of DPI awareness have been fixed.) In the latest version, dragging a window from a high DPI screen to a low DPI screen does correctly result in all of the window controls (client and non-client) and the console text being drawn at a size appropriate for the current display's DPI. ( However, the physical dimensions of the window are not adjusted at all. Consider a ConEmu window on a 200% DPI display at 80×25 characters. The window is approx 1200×900 pixels, and physically measures 5"×3½" if you hold a ruler up to your monitor.
Drag this window to a secondary 100% DPI display. This is the bug: the window remains 1200×900px. Because it is on a low DPI display, it physically measures approx 11"×8½" — roughly double its size compared to the high DPI display. Additionally, the text content does not resize properly: it is still rendered as 80×25 characters, resulting in lots of wasted space.
If you manually resize the window by dragging borders or even maximizing & restoring, the console dimensions are recalculated and the text is redrawn correctly, although the window remains roughly double the physical size as it was before moving, which is undesirable.
So in order to keep the same character dimensions (and thus roughly same physical size), you must manually drag the window until you get your desired size. In this case, that means resizing to 644×472 pixels (physically 6"×4").
And then if you drag the window back to the 200% DPI display, this all happens again in reverse, with the window becoming too small after dragging. (And text is now clipped because it overflows.)
I believe the solution to this last remaining DPI problem is relatively simple: after ConEmu receives a |
|
I would like to see Log Files with these steps. |
|
Log files: ConEmu-gui-2292.log Steps:
|
Not 100% sure this is a conemu issue, but other applications don't seem to have the problem.
I have a dual monitor setup, a laptop with a high dpi screen and a second (normal monitor). The high dpi screen is set to 250% for text, apps, .. in windows display settings and the normal screen has 100%.
Now, when I drag conemu to my second screen, it becomes extremely large (larger then the screen), so I'm guessing it's not adjusting to the 100% setting of the second screen. The toolbar of conemu is also extremely large on the second screen (as well as the putty console, but that might be another problem).