4 ms·

> Nearly all my displays are HiDPI now. Well, that's the whole thing. HiDPI in and of itself works well. I use it with a 24" UHD monitor and I absolutely love

> Nearly all my displays are HiDPI now. Well, that's the whole thing. HiDPI in and of itself works well. I use it with a 24" UHD monitor and I absolutely love the setup. But the main issue with Linux, at least with X11, is that it doesn't handle multiple displays with different DPI settings. As you noted, QT seems to work fine, as do some other toolkits that have dynamic scaling according to the monitor size. Alacritty does this too, for example (don't know what toolkit they use, though). But GTK in particular is terrible. Yes, you can configure it to use scaling, in which case it works well, IF you don't need fractional scaling (though recent versions of Gnome seem to support it somehow). But now, if you're going to use, say, a HiDPI laptop with a "regular", larger external monitor, you're gonna have a bad time. If you enable scaling, the widgets will be huge on the LoDPI display. If you disable it, widgets will be teeny tiny on the HiDPI one.

badsectoracula 5y ago
Note that the problem isn't really with X11 (or at least Xorg) since it does provide the necessary information via RandR to perform per-monitor scaling. The issue is really with window managers and toolkits. What needs to happen is that window managers ask the applications (the top level windows really) to scale themselves -this can be done not just for DPI purposes- and then the applications should apply that scaling. (applications should expose that they can support this - like they expose that they support handling a 'close window' event - so that compositing window managers can do it themselves for applications that do not support it, which is also why this needs to go through the window manager) Qt can do this but AFAIK window managers do not do this because there isn't any standard events for that - i remember an email about this exact topic when i took a look at the Xorg mailing list for WMs some time ago, but it didn't seem to be going anywhere (in that it barely had any replies). So it really is about standardizing how it is to be done. I think the main reason it isn't done is that such setups are comparably rare (i mean hidpi displays themselves are very rare - if you check any desktop resolution stats they often barely are a blip - and having both a hidpi display and a regular dpi one is even less common than that) so developers aren't that interested in implementing such a thing. One way it could be done however is also pushing the idea that this isn't just for multimonitor setups: as i wrote above, you can use that for generic scaling, which is useful even for single monitor regular dpi setups (if anything it can be very useful for low resolution setups - like 1366x768 and similar which are way more common than hidpi - when faced with applications with a lot of padding, etc).
- grishka 5y ago
  The issue with Linux is that nothing is part of the system. There's no single standard GUI toolkit. There's no single standard windowing system. There's way too many variations of everything.
  - herbst 5y ago
    Some of us don't call that an issue ;) it just makes discussions about what's possible more complicated
  - badsectoracula 5y ago
    This isn't really an issue, you just need people to agree around doing some common stuff (even if they do their own stuff elsewhere). And this is really not that dissimilar under Windows: nowadays you have a lot of different GUI toolkits and applications still need to "opt-in" and explicitly support stuff like scaling, so you have a lot of applications that do not do that.
    - pjmlp 5y ago
      They don't even agree with what they are supposed to support from freedesktops.org. On Windows, Win32 doesn't do that by default because it would break backwards compatibility from those Windows 95 binaries being run on a Windows 10 2021 edition, so it must be a conscious decision to enable it. UWP and WinUI work just fine.
      - badsectoracula 5y ago
        Yeah but practically nobody really uses UWP so it doesn't count :-P
        pjmlp 5y ago
        Windows 11 will change that, as everything gets merged back into Win32 and WinUI takes its place as official UI framework, even for .NET applications.

badsectoracula 5y ago

Note that the problem isn't really with X11 (or at least Xorg) since it does provide the necessary information via RandR to perform per-monitor scaling. The issue is really with window managers and toolkits. What needs to happen is that window managers ask the applications (the top level windows really) to scale themselves -this can be done not just for DPI purposes- and then the applications should apply that scaling. (applications should expose that they can support this - like they expose that they support handling a 'close window' event - so that compositing window managers can do it themselves for applications that do not support it, which is also why this needs to go through the window manager) Qt can do this but AFAIK window managers do not do this because there isn't any standard events for that - i remember an email about this exact topic when i took a look at the Xorg mailing list for WMs some time ago, but it didn't seem to be going anywhere (in that it barely had any replies). So it really is about standardizing how it is to be done. I think the main reason it isn't done is that such setups are comparably rare (i mean hidpi displays themselves are very rare - if you check any desktop resolution stats they often barely are a blip - and having both a hidpi display and a regular dpi one is even less common than that) so developers aren't that interested in implementing such a thing. One way it could be done however is also pushing the idea that this isn't just for multimonitor setups: as i wrote above, you can use that for generic scaling, which is useful even for single monitor regular dpi setups (if anything it can be very useful for low resolution setups - like 1366x768 and similar which are way more common than hidpi - when faced with applications with a lot of padding, etc).

grishka 5y ago
The issue with Linux is that nothing is part of the system. There's no single standard GUI toolkit. There's no single standard windowing system. There's way too many variations of everything.
- herbst 5y ago
  Some of us don't call that an issue ;) it just makes discussions about what's possible more complicated
- badsectoracula 5y ago
  This isn't really an issue, you just need people to agree around doing some common stuff (even if they do their own stuff elsewhere). And this is really not that dissimilar under Windows: nowadays you have a lot of different GUI toolkits and applications still need to "opt-in" and explicitly support stuff like scaling, so you have a lot of applications that do not do that.
  - pjmlp 5y ago
    They don't even agree with what they are supposed to support from freedesktops.org. On Windows, Win32 doesn't do that by default because it would break backwards compatibility from those Windows 95 binaries being run on a Windows 10 2021 edition, so it must be a conscious decision to enable it. UWP and WinUI work just fine.
    - badsectoracula 5y ago
      Yeah but practically nobody really uses UWP so it doesn't count :-P
      - pjmlp 5y ago
        Windows 11 will change that, as everything gets merged back into Win32 and WinUI takes its place as official UI framework, even for .NET applications.