search

Maximus5 / conemu-old-issues

Old issues imported from googlecode. Project was moved to
https://conemu.github.io
6 stars 1 forks source link

UI scaling on windows #1185

Open Maximus5 opened 9 years ago

Maximus5 commented 9 years ago

Originally reported on Google Code with ID 1185

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.

Reported by typeof.net on 2013-08-09 15:41:00

Maximus5 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.

Reported by Firehawke on 2013-10-22 10:58:45

Maximus5 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.

Reported by ConEmu.Maximus5 on 2013-10-22 14:08:31

Maximus5 commented 9 years ago

Reported by ConEmu.Maximus5 on 2013-10-22 14:10:06

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

Reported by ConEmu.Maximus5 on 2013-10-28 13:27:02

Maximus5 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.

Reported by cheuer on 2014-06-24 17:10:31

Maximus5 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.

Reported by achalddave on 2014-07-03 18:14:54

Maximus5 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.

Reported by roel.vanhout on 2014-12-10 10:38:48

Maximus5 commented 9 years ago 
Attach LogFiles after opening Settings dialog

Reported by ConEmu.Maximus5 on 2014-12-10 11:11:20

Maximus5 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.

Reported by ConEmu.Maximus5 on 2014-12-10 11:14:11

Maximus5 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.

Reported by cheuer on 2014-12-11 23:18:33

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

Reported by ConEmu.Maximus5 on 2014-12-11 23:28:50

Maximus5 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.

Reported by cheuer on 2014-12-11 23:46:47

Maximus5 commented 9 years ago

Reported by ConEmu.Maximus5 on 2014-12-21 06:51:58

Maximus5 commented 9 years ago 
Issue 1844 has been merged into this issue.

Reported by ConEmu.Maximus5 on 2014-12-21 06:52:37

Maximus5 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!

Reported by ConEmu.Maximus5 on 2014-12-21 06:55:05

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

Reported by cheuer on 2014-12-21 07:09:15

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

Reported by ConEmu.Maximus5 on 2014-12-21 09:38:58

Maximus5 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.

Reported by ConEmu.Maximus5 on 2014-12-21 09:43:51

Maximus5 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.

Reported by cheuer on 2014-12-21 18:53:21

Maximus5 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.

Reported by cheuer on 2014-12-22 15:46:01

Maximus5 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.

Reported by cheuer on 2014-12-22 15:49:54

Maximus5 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!

Reported by cheuer on 2015-01-29 17:57:03

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

Reported by ConEmu.Maximus5 on 2015-01-29 18:30:07

Maximus5 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.

Reported by cheuer on 2015-01-29 20:11:51

Maximus5 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.

Reported by ConEmu.Maximus5 on 2015-01-29 20:48:15

Maximus5 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.

Reported by ConEmu.Maximus5 on 2015-01-29 20:58:03

Maximus5 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.

Reported by cheuer on 2015-01-29 22:23:19

Maximus5 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...

Reported by ConEmu.Maximus5 on 2015-01-29 23:08:01

Maximus5 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.

Reported by cheuer on 2015-01-29 23:29:12

Maximus5 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?

Reported by jaykul@huddledmasses.org on 2015-01-30 07:22:40

Maximus5 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!

Reported by ConEmu.Maximus5 on 2015-01-30 09:00:18

Maximus5 commented 9 years ago

Reported by ConEmu.Maximus5 on 2015-01-30 09:09:06

Maximus5 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.

Reported by cheuer on 2015-01-30 16:12:36

Maximus5 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.

Reported by ConEmu.Maximus5 on 2015-01-30 16:16:37

Maximus5 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.

Reported by cheuer on 2015-01-30 16:29:22

Maximus5 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.

Reported by ConEmu.Maximus5 on 2015-01-30 16:46:56

Maximus5 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).

Reported by mb97531 on 2015-01-30 17:43:52

Maximus5 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.

Reported by jaykul@huddledmasses.org on 2015-02-01 07:10:18