| 1 |
Hello friends, |
| 2 |
|
| 3 |
On Fri, Sep 1, 2017 at 12:16 PM, Grant <emailgrant@×××××.com> wrote: |
| 4 |
>> My laptop's 13" screen has a native resolution of 3200x1800 which |
| 5 |
>> makes everything crazy small on-screen. Is there a good method for |
| 6 |
>> telling Xorg or xfce4 to compensate, or should I one-at-a-time my |
| 7 |
>> applications? I can adjust the resolution down but it makes the |
| 8 |
>> colors look weird. |
| 9 |
> |
| 10 |
|
| 11 |
Which laptop do you have? I would recommend configuring applications |
| 12 |
one at a time and submitting bug reports to applications which are not |
| 13 |
sufficiently configurable. |
| 14 |
|
| 15 |
> After some more research, it turns out this is a pretty well-known |
| 16 |
> problem on the Linux desktop (it's called HiDPI) without a good |
| 17 |
> solution... except for this: |
| 18 |
> |
| 19 |
|
| 20 |
The problems quoted here still apply to Windows despite Microsoft |
| 21 |
exercising complete control over the display subsystem. On OSX, Apple |
| 22 |
decided to specify UI sizes in "points" by default and require that |
| 23 |
programs make API calls to enable HiDPI awareness. This has its own |
| 24 |
problems, and can make things look worse. Surprisingly I find myself |
| 25 |
agreeing with Microsoft's solution more often than not. Regardless of |
| 26 |
my opinion, Apple's solution is impossible to implement on Linux as |
| 27 |
there is no controlling body that dictates how X11/Wayland toolkits |
| 28 |
work. |
| 29 |
|
| 30 |
Most issues are in individual programs and libraries and can't be |
| 31 |
solved at the same time. If I want to render something and be HiDPI |
| 32 |
aware, I must: |
| 33 |
0) Have appropriately sized assets for higher resolutions. Most |
| 34 |
programs fail this step. |
| 35 |
1) Retrieve the display metrics. |
| 36 |
2) Use the display metrics to calculate all sizes. |
| 37 |
|
| 38 |
Without #0, menu items will look extremely grainy if they are |
| 39 |
enlarged. The UI will be usable but it will be extremely unpleasant to |
| 40 |
look at. There are some Microsoft-authored programs that use this |
| 41 |
strategy, and all unupdated OSX programs do this. |
| 42 |
|
| 43 |
Even if a programmer attempts #2, there are a lot of sizes. It can be |
| 44 |
extremely hard to position a window or size it in anything but pixels |
| 45 |
and some positioning mechanisms do not take relative locations. There |
| 46 |
may be interfaces that one needs to interact with that are not |
| 47 |
specific in how sizes are specified, and the application developer may |
| 48 |
not have access to a HiDPI screen. |
| 49 |
|
| 50 |
|
| 51 |
On Fri, Sep 1, 2017 at 12:28 PM, Mart Raudsepp <leio@g.o> wrote: |
| 52 |
> Ühel kenal päeval, R, 01.09.2017 kell 10:16, kirjutas Grant: |
| 53 |
>> > My laptop's 13" screen has a native resolution of 3200x1800 which |
| 54 |
>> > makes everything crazy small on-screen. Is there a good method for |
| 55 |
>> > telling Xorg or xfce4 to compensate, or should I one-at-a-time my |
| 56 |
>> > applications? I can adjust the resolution down but it makes the |
| 57 |
>> > colors look weird. |
| 58 |
>> |
| 59 |
>> |
| 60 |
>> After some more research, it turns out this is a pretty well-known |
| 61 |
>> problem on the Linux desktop (it's called HiDPI) without a good |
| 62 |
>> solution... except for this: |
| 63 |
>> |
| 64 |
>> https://forums.linuxmint.com/viewtopic.php?t=159064 |
| 65 |
>> https://bugs.freedesktop.org/show_bug.cgi?id=94816 |
| 66 |
>> |
| 67 |
>> The solution is to patch xrandr with the capability to do nearest |
| 68 |
>> neighbor filtering and run xrandr like this: |
| 69 |
>> |
| 70 |
>> xrandr --output eDP1 --mode "3200x1800" --scale "0.5x0.5" |
| 71 |
>> |
| 72 |
>> It works great. |
| 73 |
>> |
| 74 |
> |
| 75 |
> I don't see how it can be called great. This is pretty much losing most |
| 76 |
> of the benefits you have with a HiDPI screen, by just making it be |
| 77 |
> almost the same as a 1600x900 screen, except the scaling involves some |
| 78 |
> nearest neighbor filtering, which sometimes might be good, sometimes |
| 79 |
> bad, and never as good as rendering things in HiDPI. |
| 80 |
> |
| 81 |
|
| 82 |
I think this might be an acceptable solution, but I would suggest |
| 83 |
turning antialiasing off so fonts are shown with crisp edges. |
| 84 |
|
| 85 |
> For HiDPI you want the toolkit to support it properly and configure it |
| 86 |
> as such. GTK+3 is such a toolkit, but outside of GNOME (where it works |
| 87 |
> out of the box), I don't know what exactly it takes to set things up. |
| 88 |
> Plus you'll need a solution for your gtk2/whatever other things, |
| 89 |
> preferably one that doesn't make things worse for gtk3 things, like |
| 90 |
> that xrandr hack does. |
| 91 |
> |
| 92 |
|
| 93 |
I would recommend switching to a CLI workflow. Then all that needs to |
| 94 |
be set up properly is your terminal emulator. |
| 95 |
|
| 96 |
R0b0t1. |
Archives