search

TobiasChe / conemu-maximus5

Automatically exported from code.google.com/p/conemu-maximus5
0 stars 0 forks source link

UI scaling on windows #1185

Open GoogleCodeExporter opened 9 years ago

GoogleCodeExporter commented 9 years ago 
Required information!
OS version: windows 7 x64 / windows 8.1 preview x64
ConEmu version: 130726 x86
Far version (if you are using Far Manager): none

I set DPI scaling to 150% (120 dpi) in windows, and i saw Explorer window 
scaled up correctly, but conemu just keep its original size.

Original issue reported on code.google.com by typeof....@gmail.com on 9 Aug 2013 at 3:41

Attachments:

GoogleCodeExporter commented 9 years ago 
This becomes a potential major pain for users who switch up to Windows 8.1 and 
the new automatic DPI adjustment.

Original comment by Fireha...@gmail.com on 22 Oct 2013 at 10:58

GoogleCodeExporter commented 9 years ago 
This is real obstruction for me.
IMHO, terminal can't be compared to other "ordinary" GUI application.
In the ConEmu setup you choose cell height in pixels but not "lines" or any 
other DPI independent values.
Decision was not taken yet.

Original comment by ConEmu.Maximus5 on 22 Oct 2013 at 2:08

GoogleCodeExporter commented 9 years ago

Original comment by ConEmu.Maximus5 on 22 Oct 2013 at 2:10

Attachments:

GoogleCodeExporter commented 9 years ago 
Issue 1306 has been merged into this issue.

Original comment by ConEmu.Maximus5 on 28 Oct 2013 at 1:27

GoogleCodeExporter commented 9 years ago 
This problem is more pronounced on Windows 8.1 with a hi-dpi monitor. Here's 
what ConEmu looks like on my 28" 4K monitor. I have placed it next to a regular 
Cygwin window, which isn't High DPI aware but Windows is scaling up the display 
to the correct size automatically.

I know I can just increase the font size, but the buttons in the tab bar are 
still tiny, and since I'm using a symlink to put the ConEmu.xml file in 
dropbox, my computer at home will also show a giant font so I'd like to avoid 
doing this if possible.

Original comment by che...@gmail.com on 24 Jun 2014 at 5:10

Attachments:

GoogleCodeExporter commented 9 years ago 
My problem with this is more about the buttons. The fonts are all fine now, and 
the actual terminal screen is alright. But the buttons on the top right are 
incredibly small. I don't use them very often, but it would be nice to get 
larger versions of them.

Original comment by achaldd...@gmail.com on 3 Jul 2014 at 6:14

GoogleCodeExporter commented 9 years ago 
The DPI scaling isn't working properly. I have a high dpi (3200x1800) laptop 
screen as primary monitor and a 1680x1050 secondary monitor. I have Windows8.1, 
'one scaling level for all displays' turned off. When I start conemu it always 
opens on the first (high dpi) monitor. When I open the settings dialog, and 
drag it to the second monitor, it looks like the attached screenshot. 
Furthermore, when I drag the conemu window itself to the second monitor, the 
title bar and window borders are scaled (it looks like 250 or 300%), too, which 
they shouldn't be.

Original comment by roel.van...@gmail.com on 10 Dec 2014 at 10:38

Attachments:

GoogleCodeExporter commented 9 years ago 
Attach LogFiles after opening Settings dialog

Original comment by ConEmu.Maximus5 on 10 Dec 2014 at 11:11

GoogleCodeExporter commented 9 years ago 
And non-client  (title bar e.g.) area is not available for "scaling" at all.
Compare with "calc.exe" which is per-monitor-dpi-aware.

Original comment by ConEmu.Maximus5 on 10 Dec 2014 at 11:14

GoogleCodeExporter commented 9 years ago 
I think that something changed in a recent build, because the scaling used to 
work ok. I did some testing on a 3-monitor setup, all with different 
resolutions. It appears that for the main window, the text and buttons are all 
scaling properly, but the actual window size is not. In the settings dialog, 
the window size mostly adjusts, but the text does not.

I have attached the log files created by running with the /log parameter. My 
monitors are arranged like this, with the center monitor set as primary:
(3200x1800)       (3840x2160)       (1050x1680)

ConEmu opens on my left-most monitor. I moved it to the center monitor, let go, 
moved it to the right monitor, let go again, then moved it to the left-most 
monitor again. I then opened the settings dialog and repeated the same 
movements.

When I compared it with calc.exe, I notice that the title bar changes height 
when I move it between monitors, but with ConEmu the text inside the window 
changes while the status bar remains the same.

Please let me know if I can provide any other information to track down this 
issue. If desired I'm happy to go through the build archives and find the last 
version that worked ok.

Original comment by che...@gmail.com on 11 Dec 2014 at 11:18

Attachments:

GoogleCodeExporter commented 9 years ago 
May be you have not enabled "per-monotor" dpi in settings? Attach ConEmuXml

Original comment by ConEmu.Maximus5 on 11 Dec 2014 at 11:28

GoogleCodeExporter commented 9 years ago 
Oh I definitely have it set, it's adjusting the text within the main window 
just fine, just not the window title or the text within settings.

ConEmu.xml attached.

Original comment by che...@gmail.com on 11 Dec 2014 at 11:46

Attachments:

GoogleCodeExporter commented 9 years ago

Original comment by ConEmu.Maximus5 on 21 Dec 2014 at 6:51

GoogleCodeExporter commented 9 years ago 
Issue 1845 has been merged into this issue.

Original comment by ConEmu.Maximus5 on 21 Dec 2014 at 6:52

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
By the time I know only one MS application (from Windows 8.1) which is really 
per-monitor-dpi-aware.
This is, surprisingly, an Internet Explorer!

Compare non-client area (caption and border) behavior with it.

And I'm still waiting for LogFiles from those users who get broken Settings 
dialog!

Original comment by ConEmu.Maximus5 on 21 Dec 2014 at 6:55

GoogleCodeExporter commented 9 years ago 
I did attach log files from the broken DPI on settings dialog. See comment #10.

Original comment by che...@gmail.com on 21 Dec 2014 at 7:09

GoogleCodeExporter commented 9 years ago 
@cheuer
Does your the dialog problems look like in comment #7? You haven't attached 
screenshots illustrating you problems.

Original comment by ConEmu.Maximus5 on 21 Dec 2014 at 9:38

GoogleCodeExporter commented 9 years ago 
@all

Just created small tool showing dpi-awareness of processes running on your PC.
https://github.com/Maximus5/CheckDpiAwareness

Interesting that even Explorer.exe (file browser window but not a taskbar) is 
SystemAware!

So the only valid comparison of caption/border behavior - Internet explorer.

Chrome and FireFox are SystemAware too.

Original comment by ConEmu.Maximus5 on 21 Dec 2014 at 9:43

GoogleCodeExporter commented 9 years ago 
The effect is not as bad as #7 but it is still hard to read the labels in the 
settings dialog. I can attach screenshots when I get to work tomorrow.

Original comment by che...@gmail.com on 21 Dec 2014 at 6:53

GoogleCodeExporter commented 9 years ago 
Here are screenshots of the settings dialog on each of the three monitors I 
described in comment #10, where I attached the log files.

Original comment by che...@gmail.com on 22 Dec 2014 at 3:46

Attachments:

GoogleCodeExporter commented 9 years ago 
Just found out, if I move ConEmu to my main monitor (3840x2160 resolution) 
before opening the settings, then it looks fine. It only gets jumbled if it 
starts on or gets moved to my other monitors.

Original comment by che...@gmail.com on 22 Dec 2014 at 3:49

Attachments:

GoogleCodeExporter commented 9 years ago 
Just got the update to version 150119a, and the settings window now looks 
great! Thanks for the fix. The only remaining DPI issue that I see is that the 
main ConEmu window doesn't resize when I drag it to a different monitor (the 
font changes and looks great, but not the window size).

By the way, love the new icon!

Original comment by che...@gmail.com on 29 Jan 2015 at 5:57

GoogleCodeExporter commented 9 years ago 
I believe it must not. Compare to IE.

Original comment by ConEmu.Maximus5 on 29 Jan 2015 at 6:30

GoogleCodeExporter commented 9 years ago 
I see that IE also does not, but Internet Explorer is probably the worst 
application one could possibly use as an example of correct behavior. Yes it 
happens to be the only native Windows 8.1 app that is per-monitor DPI aware, 
but that doesn't mean it's the perfect example, it just means that the Desktop 
Window Manager isn't going to change its scaling.

From my reading of the DPI-awareness pages on MSDN, it seems that the only 
difference between the PerMonitorAware apps and the SystemAware apps is the 
behavior of DWM. Apps that are only SystemAware are declaring that they are 
only checking the system DPI, and are relying on DWM to scale them up or down 
based on the difference between the system DPI and the current monitor DPI. 
This is why the title bars of apps such as explorer.exe, calc.exe change when 
you move them, because DWM is scaling the entire app to match the monitor DPI. 
Apps that declare they are checking the per-monitor DPI should be handling all 
scaling themselves, so DWM leaves them alone (see 
https://msdn.microsoft.com/en-us/library/windows/desktop/dn469266(v=vs.85).aspx#
comparison_of_dpi_awareness_levels).

I get that this means you can't control the size of the title bar and border. I 
think that particular issue lies at Microsoft's feet, and I can live with it.

However, that doesn't mean you shouldn't adjust the window size, and I think IE 
is doing it wrong. See this link 
(https://msdn.microsoft.com/en-us/library/windows/desktop/dd464659(v=vs.85).aspx
), it states that a per-monitor DPI aware app "Changes window dimensions to 
maintain a physical size that appears consistent on any display." Furthermore, 
because the scaling of the text is changing but the window does not, the number 
of rows & columns of text is also changing, but I think these should be kept 
consistent so that the output from one command will still be visible if you 
move the window to a monitor with a different DPI.

Sorry for being so long-winded, and I hope this all makes sense. I did some 
searching and the only other program I could find that implemented per-monitor 
DPI scaling is VirtualDub, so there just aren't a lot of examples to look at. 
There's an example app linked from the MSDN article above, but it appears you 
need Visual Studio Ultimate 2013 to build it.

Original comment by che...@gmail.com on 29 Jan 2015 at 8:11

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
1. Show me another per-monitor DPI aware app. From my experience the IE is the 
only one.
https://github.com/Maximus5/CheckDpiAwareness

2. The words "maintain a physical size" are weird and confusing... What is that 
"physical size"? For example, I have 20" 1920x1200 and 50" 1920x1080 monitors. 
How must behave ConEmu while jumping from one to another?

OK. May be it may be correct to keep relative size of the window (aka 
percentage of monitor space). Attach your LogFiles and screenshots (to 
elucidation), I'll check if it can be true.

Original comment by ConEmu.Maximus5 on 29 Jan 2015 at 8:48

GoogleCodeExporter commented 9 years ago 
> the number of rows & columns of text is also changing,
> but I think these should be kept consistent so that the output
> from one command will still be visible if you move the window
> to a monitor with a different DPI.

That can't be true to all possible configurations... Nobody can guarantee that 
next monitor can hold the same rows/cols as previous. Exactly in my case it 
cant.

Original comment by ConEmu.Maximus5 on 29 Jan 2015 at 8:58

GoogleCodeExporter commented 9 years ago 
As stated, the only per-monitor DPI aware app I could find is VirtualDub. It is 
available here: http://virtualdub.sourceforge.net/

The problem with IE is that it is declaring that it's per-monitor aware, but 
it's not implemented correctly by not changing the window size when moved to a 
monitor with a different DPI.

"Maintain a physical size" means that if I hold up a ruler to my monitor and 
see that the window is about 6 inches wide, when I move it to the other monitor 
the scaling should adjust so it ends up about 6 inches wide there too. This 
would probably use the same math you're already doing to change the font size.

If you're keeping the physical size constant, you are right in that the next 
monitor won't always be able to hold the same rows/cols. But if I had ConEmu 
open in a small portion (less than the size of the smaller monitor) and then 
move it over, it would be able to. I think this will already work out if you 
just apply the same font scaling to the window size.

Attaching logs. For this test I opened ConEmu, moved it to my primary, 144 DPI 
monitor, ran the "ls" command, moved it back to the 192 DPI monitor, and ran ls 
again.

Original comment by che...@gmail.com on 29 Jan 2015 at 10:23

Attachments:

GoogleCodeExporter commented 9 years ago 
> As stated, the only per-monitor DPI aware app I could find is VirtualDub.

Yep. It's per-monitor indeed. But it behaves in weird way... Take a look at 
screenshots. After jump the window is trimmed!

> "Maintain a physical size" means that if I hold up a ruler to my monitor
> and see that the window is about 6 inches wide, when I move it to the other
> monitor the scaling should adjust so it ends up about 6 inches wide there too.
> This would probably use the same math you're already doing to change the font 
size.

As I've said be before that will be bad behavior too. My secondary monitor has 
physical 44 dpi (yeah, it's a TV). If ConEmu will maintain *physical* size - it 
will be *too* small because secondary monitor is more than a twice as large! 
Moreover, the text will be almost unreadable because of you are watching TV 
from sofa :)

DpiAware'ness is one of the most indistinct and equivocal things in 
computer/application design...

Original comment by ConEmu.Maximus5 on 29 Jan 2015 at 11:08

Attachments:

GoogleCodeExporter commented 9 years ago 
If the physical size is staying the same, then that is the correct behavior. 
Yeah it's a bit inconvenient, but I would expect to have to manually resize the 
window to fit the smaller screen before moving it over. This is the way that 
non-dpi aware apps are working currently, since DWM is just doing the scaling. 
Take a SystemAware app like Chrome, make it almost fill the 50" screen, then 
drag it over to the smaller one, and DWM will change the scaling to keep the 
window the same size, which is way too big to fit the screen.

The ideal behavior is to do it exactly like the SystemAware and Unaware apps, 
but since you're setting it directly there won't be the blurriness that is 
visible when DWM changes the scaling.

Original comment by che...@gmail.com on 29 Jan 2015 at 11:29

GoogleCodeExporter commented 9 years ago 
Yeah, definitely don't emulate VirtualDub -- that behavior of resizing the 
window is one you already tried ;)

It's that weird thing where if I drag it from one window to the other it 
resizes one way, but if I use Win+Shift+LeftArrow it resizes differently (and 
changes the proportions of the window). Insanity.

By the way, on my monitors VirtualDub x64 seems to change the window size 
without rescaling the contents of the window -- does that not happen to you?

Original comment by jay...@huddledmasses.org on 30 Jan 2015 at 7:22

GoogleCodeExporter commented 9 years ago 
I don't want to implement weird unfriendly behavior. If one resize the window 
to maintain its physical size - that size may easily exceed monitor space. And 
it'll be a pain to shrink the window, the window borders are obscured...

The behavior must be user-friendly regardless of MS "recommendations". Hey, 
there are no apps following them!

Original comment by ConEmu.Maximus5 on 30 Jan 2015 at 9:00

GoogleCodeExporter commented 9 years ago

Original comment by ConEmu.Maximus5 on 30 Jan 2015 at 9:09

GoogleCodeExporter commented 9 years ago 
In my case, if I move ConEmu from my 192 DPI monitor to the 96 DPI one, the 
window is larger than the screen and is a pain to resize. However, if the 
physical size was kept then it would fit. There is no way to cover every single 
use case, and keeping the physical size seems to make the most sense to me 
since that's the behavior in all other apps (except IE). Maybe that will change 
when more apps implement DPI awareness.

Original comment by che...@gmail.com on 30 Jan 2015 at 4:12

GoogleCodeExporter commented 9 years ago 
Physical size? Never. Reasons above...
Add I'd said before most proper way, I believe, will be maintaining percentage 
of monitor workspace.

Original comment by ConEmu.Maximus5 on 30 Jan 2015 at 4:16

GoogleCodeExporter commented 9 years ago 
What about matching the current "Window size" setting? If cells, then adjust 
the window to keep that number of cells, if pixels then keep it as currently 
implemented, and if % then adjust to match monitor percentage.

Original comment by che...@gmail.com on 30 Jan 2015 at 4:29

Attachments:

GoogleCodeExporter commented 9 years ago 
In my case if I move the window from primary to secondary - I'll get decreased 
rows/cols amount. So after returning the window to the primary monitor the 
window will be smaller that expected... Hm. But may be that is most sane 
behavior at the moment.

Original comment by ConEmu.Maximus5 on 30 Jan 2015 at 4:46

GoogleCodeExporter commented 9 years ago 
Perhaps, maintain a user preferred window size (upws). At start-up, the upws is 
taken from the saved settings. When moving from your primary to secondary 
monitor, the actual window size changes (because it has to), but the upws 
remains the same; when moving back from secondary to primary monitor, the upws 
is restored (because it can).

The upws would only change when the user resizes the window manually 
(maximize/fullscreen are NOT a manual resize).

Original comment by mb97...@gmail.com on 30 Jan 2015 at 5:43

GoogleCodeExporter commented 9 years ago 
I like the idea of trying to follow the window size setting -- most of the time 
I want my windows to at least maintain the width, in characters, since I'm not 
on Windows 10 yet, and text doesn't re-flow....

However, I also like the idea of a preferred window size! Might it be possible 
to remembering a per-monitor preferred size? In particular, I have a "retina" 
macbook pro, and (two) vertical 1080p monitors that I use for code and reading 
....

When I move ConEmu to the wider retina screen, it's usually because I need to 
make it the window wider for some reason (the retina screen is usually where 
email and file managers sit). Of course, I always have the problem that it's 
too tall (because as long as it's on the tall monitors, I tend to make it 
taller if I have a lot of help output or something, and never shrink it again). 
And again of course, when I move it back, I have to make it thinner, etc.

For what it's worth (just, you know, to explain my use style), I almost always 
move the window to the other monitor with hotkeys (Win+Shift+Arrow).

All that to say I think it probably be a neat option if ConEmu could resize to 
the size it was last time I used it on that monitor.

Original comment by jay...@huddledmasses.org on 1 Feb 2015 at 7:10