Previous Thread
Next Thread
Print Thread
High Resolution Growing Pains #34078 22 Mar 21 07:01 PM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content OP
Member
OP Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
High resolution displays (higher than 96 dpi, typically in conjunction with layouts of 1920x1280 or more) have been around for several years now, but there hasn't been much discussion of the related issues, perhaps because:

  • it's mostly just developers with the high-res displays (typically on laptops), rather than end-users
  • Windows does a decent job of auto-scaling
  • Since it requires the manual specification of the -dpm command line switch, few people even know about it, much less bother to experiment.


However, on the first point, we're starting to see a lot more multi-monitor setups, where one is normal res and the other high res. And on the second point, while the auto-scaling may be "decent", the result is typically not as sharp as it should be, effectively canceling out much of the advantage of the higher resolution.

To address that sharpness complaint, we added the -dpm ( DPI Per Monitor Awareness ) way back in 6.4.1666. The basic concept there is to disable the auto-scaling logic (in which Windows makes every monitor appear as if it were 96 dpi) and leave it to the application to deal directly with the true monitor resolution. Unfortunately, that's not as simple as it sounds, especially in a multi-monitor mixed-resolution environment. When things don't go right, the result is that you enter have entire windows or dialogs that are way too big, or way too small, or parts of them (text, tool bars, buttons, etc.) that aren't scaled compatibly with the rest of it. In A-Shell's case, it remains a work in progress. But I think the objective should probably be to handle it so that it "just works", without calling much attention to itself (and eliminating the need for a special switch).

Which leads to the 3rd point above. As it stands, switching between the normal and -dpm modes requires manually adjusting the command line, and that produces an immediate effect that is typically not desirable. Assuming you have a high-res monitor, activating the -dpm switch will cause the initial main window size to be much smaller than before (not a good first impression). Of course, all you have to do is manually resize it, then use File > Save to save the updated configuration, and that problem goes away. But if you then remove the -dpm, you get the opposite problem: the initial window becomes too big. And if it spans monitors, you get the strange effect of one part of the window being bigger than the other due to the different monitor resolutions.

So I think if we are going to ever migrate to the -dpm environment as the default, we're going to have to make some adjustment to eliminate the initial shock to unsuspecting users. My thinking here is that probably the optimum adjustment to this specific problem (the initial window size) would be to just treat the saved window coordinates as normalized to 96 DPI (essentially adopt the Windows auto-scaling scheme). The would create a one-time annoyance for those who have already switched over to -dpm, but that's a much smaller (and more power-user-oriented) group.

If anyone out there is actually using -dpm mode, I'd be interested in any feedback about other problems they've encountered.

Re: High Resolution Growing Pains [Re: Jack McGregor] #34082 23 Mar 21 01:28 PM
Joined: Sep 2002
Posts: 5,450
F
Frank Online Content
Member
Online Content
Member
F
Joined: Sep 2002
Posts: 5,450
Cap - are you talking about having a user "drag" your app from 1 monitor to the other? Or actually maintaining 2 active displays at once and just moving the mouse from left to right?

Re: High Resolution Growing Pains [Re: Jack McGregor] #34083 23 Mar 21 03:09 PM
Joined: Jun 2001
Posts: 11,645
J
Jack McGregor Online Content OP
Member
OP Online Content
Member
J
Joined: Jun 2001
Posts: 11,645
The dpi-related problems are mainly related to moving windows between monitors. Once you get your windows set up, there's no real issue moving the mouse and focus between them. (So again, it tends to affect developers and power users more than the "typical" end-users who may be more focused on a single app.)


Moderated by  Jack McGregor, Ty Griffin 

Powered by UBB.threads™ PHP Forum Software 7.7.3