3 ms·

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 is

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.
- vetinari 5y ago
  For decades, the standard windowing system was X11; and not just for Linux, for other systems as well. The issue was elsewhere - it provided standardized wire protocol and you could not break it. It could extend it, but applications not aware of the extension would be not able to benefit. Windows and Mac on the other hand kept the protocol proprietary and you had to use supplied libraries, you could not talk to the display server directly. So Microsoft and Apple could update these libraries; on Linux, there was no such option, all the apps using wire protocol instead of client libraries would be left out in the dark.
vetinari 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. It is issue with X11. If you have Wordperfect binary from 1999, it still has to work; it does not matter that RandR provides information, old clients will not ask for it and without it, they will be broken. That's why Xwayland does upscaling by itself. > 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 Cause and effect. They are rare, because using them sucks, making them even rarer. On systems, where they do not suck, they are not that rare. This attitude makes entire platform worse off.
- badsectoracula 5y ago
  > It is issue with X11. If you have Wordperfect binary from 1999, it still has to work; it does not matter that RandR provides information, old clients will not ask for it and without it, they will be broken. This is why i wrote "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". You do not need X11 support for that, functionality that exist can be used right now to do it - assuming the applications and WMs cooperate to specify the necessary attributes and events, of course. > That's why Xwayland does upscaling by itself. You can also do this with a compositor for applications that do not support scaling themselves (which would be the default state - again this isn't any different than the 'supports close event' flag that already exists for decades now). Without a compositor you're out of luck (for the most part)... ...However! Keith Packard worked on server-side scaling some time ago [0] (not sure if it was merged with mainline) which would allow this to be done even without a compositor (well, kinda, technically the server does the compositing just for the scaled windows). So even without a regular desktop compositor this should still be implementable, assuming that functionality was (or will be) merged in mainline Xorg. But note that this is only for the case where one wants to run applications that do not support scaling and have hidpi scaling and also not using a compositor. The rest can already be implemented with Xorg as-is. [0] https://keithp.com/blogs/window-scaling/ https://keithp.com/blogs/window-scaling/
catblast01 5y ago
> i mean hidpi displays themselves are very rare - if you check any desktop resolution stats they often barely are a blip Do you have a link/cite for this? I couldn’t find easily somewhere summarizing pixel density stats. “Desktop resolution stats” is not the same thing. All the retina displays have at least a 2x pixel ratio so these tables on a cursory Google search are clearly lumping 13 inch MacBook pros into the 1280x800 bucket for instance. You got a reference to something that clearly is accounting for pixel ratio?
- badsectoracula 5y ago
  Check Firefox stats: https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware > these tables on a cursory Google search are clearly lumping 13 inch MacBook pros into the 1280x800 bucket for instance. How can you tell that? Even JS-only trackers can use Window.devicePixelRatio to get the real resolution, if needed.
  - catblast01 5y ago
    I can tell from a number of reports available that basically have no resolutions higher than 1920x1200, when we know there are enough retina displays out there that they should be listed. As to the linked report. It’s hard to discount bias with a browser with 3% market share that looking further seems to be overwhelmingly installed on outdated Windows 8 machines
deleted 5y ago
[deleted]

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.
vetinari 5y ago
For decades, the standard windowing system was X11; and not just for Linux, for other systems as well. The issue was elsewhere - it provided standardized wire protocol and you could not break it. It could extend it, but applications not aware of the extension would be not able to benefit. Windows and Mac on the other hand kept the protocol proprietary and you had to use supplied libraries, you could not talk to the display server directly. So Microsoft and Apple could update these libraries; on Linux, there was no such option, all the apps using wire protocol instead of client libraries would be left out in the dark.

vetinari 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. It is issue with X11. If you have Wordperfect binary from 1999, it still has to work; it does not matter that RandR provides information, old clients will not ask for it and without it, they will be broken. That's why Xwayland does upscaling by itself. > 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 Cause and effect. They are rare, because using them sucks, making them even rarer. On systems, where they do not suck, they are not that rare. This attitude makes entire platform worse off.

badsectoracula 5y ago
> It is issue with X11. If you have Wordperfect binary from 1999, it still has to work; it does not matter that RandR provides information, old clients will not ask for it and without it, they will be broken. This is why i wrote "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". You do not need X11 support for that, functionality that exist can be used right now to do it - assuming the applications and WMs cooperate to specify the necessary attributes and events, of course. > That's why Xwayland does upscaling by itself. You can also do this with a compositor for applications that do not support scaling themselves (which would be the default state - again this isn't any different than the 'supports close event' flag that already exists for decades now). Without a compositor you're out of luck (for the most part)... ...However! Keith Packard worked on server-side scaling some time ago [0] (not sure if it was merged with mainline) which would allow this to be done even without a compositor (well, kinda, technically the server does the compositing just for the scaled windows). So even without a regular desktop compositor this should still be implementable, assuming that functionality was (or will be) merged in mainline Xorg. But note that this is only for the case where one wants to run applications that do not support scaling and have hidpi scaling and also not using a compositor. The rest can already be implemented with Xorg as-is. [0] https://keithp.com/blogs/window-scaling/ https://keithp.com/blogs/window-scaling/

catblast01 5y ago

> i mean hidpi displays themselves are very rare - if you check any desktop resolution stats they often barely are a blip Do you have a link/cite for this? I couldn’t find easily somewhere summarizing pixel density stats. “Desktop resolution stats” is not the same thing. All the retina displays have at least a 2x pixel ratio so these tables on a cursory Google search are clearly lumping 13 inch MacBook pros into the 1280x800 bucket for instance. You got a reference to something that clearly is accounting for pixel ratio?

badsectoracula 5y ago
Check Firefox stats: https://data.firefox.com/dashboard/hardware https://data.firefox.com/dashboard/hardware > these tables on a cursory Google search are clearly lumping 13 inch MacBook pros into the 1280x800 bucket for instance. How can you tell that? Even JS-only trackers can use Window.devicePixelRatio to get the real resolution, if needed.
- catblast01 5y ago
  I can tell from a number of reports available that basically have no resolutions higher than 1920x1200, when we know there are enough retina displays out there that they should be listed. As to the linked report. It’s hard to discount bias with a browser with 3% market share that looking further seems to be overwhelmingly installed on outdated Windows 8 machines

deleted 5y ago

[deleted]