New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Window 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] |
|
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 |
|
And I need LogFiles
|
Enabling "Treat font height as device units" does not really help -- it only makes the text bigger.
|
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. |
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. |
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: |
@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. |
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:
|
Just popping in to say I am experiencing the same issue that daguej has described on June 16, 2020 above. I am running preview build 210206. Please let me know if I can be any help, and ty for making such a great product! |
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).
The text was updated successfully, but these errors were encountered: