8 ms·

Apple and GNOME do this to avoid rounding errors when working in scalable layouts defined as screen-width percentages. Web browsers have accumulated all sorts o

Apple and GNOME do this to avoid rounding errors when working in scalable layouts defined as screen-width percentages. Web browsers have accumulated all sorts of tricks and hacks to ensure that, say, floating four 25% width columns always adds up to the same width as a 100% column. This isn't a particular failing of CSS or the web - though CSS floats absolutely make this so much of a problem that browsers have to actually correct for this when users scale pages. Exposing a 1x design to non-integer scale factors fundamentally runs the risk of breaking it - you will get odd pixel gaps or misalignments which would not occur at integer scales, because the virtual pixel coordinates no longer line up with actual screen pixels.

kuschku 5y ago
Qt has done that for many years, so has Android, so has Windows. Only macOS and Gnome don't, because they value single-pixel alignment errors more than the massive performance issues and reduced sharpness their solutions cause.
- vetinari 5y ago
  And Qt after all those years does not work correctly in HiDPI. Not even on Windows. Unlike macOS and Gnome, which do.
  - kuschku 5y ago
    Gnome does NOT work correctly in HiDPI. I’ve got 3 systems with 1.5x scale, and Qt handles them perfectly fine (even with per-monitor separate scaling). While Gnome absolutely does not. Either I get absolutely unreadable tiny 1x, or I get absolutely unusable 2x with no space for anything. (That said, Qt on Windows handles per-screen scale factors very weirdly, especially with applications using pixel values)
    - nextaccountic 5y ago
      In my screen, 1x and 2x are both inadequate, but I'm using Gnome on Wayland on 1.25 scaling right now. Gnome can do fractional scaling. You just need to configure it with a gsettings command: https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fractional-scaling.html https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fr... https://wiki.archlinux.org/title/HiDPI#Fractional_scaling https://wiki.archlinux.org/title/HiDPI#Fractional_scaling Or using gnome-tweaks. Then, on display settings, it should show up the new scaling configs. And, in Gnome it's very sharp, with zero blurring! It was somehow sharper than whatever KDE was doing when I tested it some months ago.
      - kuschku 5y ago
        Eh, no. Gnome doesn’t actually do fractional scaling – as said earlier in the thread, it’ll render at the next integer resolution and scale down in GPU. Which I don’t really have the performance for (I’m already using Budgie’s option to do exactly that under X11 right now already, it’s not exactly the most performant solution). And even under Wayland, Gnome still renders at the next integer scale. While KDE under X11 actually renders at the correct resolution, with proper scaling and perfect sharpness, which I really miss.
        md8z 5y ago
        That is working as intended, and either you don't have a graphics card that is good enough to drive your monitor, or you're using CPU-rendered apps that will always be slow at higher resolutions. This is a problem with a lot of cheap hardware and older software. It worked for Apple because IIRC they've been porting all the low level drawing over to Metal. GNOME is a lot slower to do that unfortunately, you won't see everything being GPU accelerated until GTK4 becomes widely adopted.
        kuschku 5y ago
        That’s not what I, as mostly android/web/qt dev, want though. Why should I get 50% less performance just to fix some tiny single-pixel issues on a screen where I can’t even see individual pixels?
    - vetinari 5y ago
      The principial difference between how Mutter/Gnome and Plasma/ handles hidpi is, that for Mutter/Gnome it works for old apps without any modifications, while the Plasma/Qt approach works only for apps that were modified to use the new APIs. Yes, the old app on Mutter will be upscaled, but it will be right scale on each monitor in mixed-dpi environment. Yes, even that old wordperfect from 1998. While on Plasma, non-Qt apps will have hard time. Also, you won't be able to do perfecly fine anything on 150%. How are you going to do 1-pixel wide line? Exact cursor positions? You are not going to. With hw downscaling, yes, you pay the price for larger framebuffer and you get good approximations, but you also avoid a great deal of corner cases, that most software users are running is never going to solve.
      - kuschku 5y ago
        > Also, you won't be able to do perfecly fine anything on 150%. How are you going to do 1-pixel wide line? Exact cursor positions? You are not going to. With hw downscaling, yes, you pay the price for larger framebuffer and you get good approximations, but you also avoid a great deal of corner cases, that most software users are running is never going to solve. I care more about the performance loss of rendering at excessive resolution than about the 1-pixel imperfections. > that for Mutter/Gnome it works for old apps without any modifications, while the Plasma/Qt approach works only for apps that were modified to use the new APIs. You could do a hybrid approach and render old apps at 1x/2x and down/upscale them and let updated apps render at the native resolution. At least render fonts at native resolution and only up/downscale the rest of the widgets. Scaling fonts can NOT be done by post-processing or it WILL be wrong. (MacOS only scales widgets, images and fonts will always be rendered at native resolution)
        vetinari 5y ago
        > MacOS only scales widgets, images and fonts will always be rendered at native resolution MacOS scales entire framebuffer. You can verify it by doing a screenshot and examining it.
  - vetinari 5y ago
    For downvoters - exhibit A: https://imgur.com/a/Ad0ZkmX https://imgur.com/a/Ad0ZkmX Problems like this are common, it is not app specific. If you call this a superior solution, then you haven't seen a really working one.
    - Vogtinator 5y ago
      Looks like that application explicitly uses (device) pixel sizes. That issue is common, but still application specific.
      - vetinari 5y ago
        In that case, it is still the problem of the approach that Qt has chosen. With macOS or Gnome, even apps from 90's that were newer updated, will have proper scale. They might be blurry (macOS upscales using nearest neighbor so it is pixelated, Gnome uses bilinear, so it is blurry instead), but they will be correct size. The Qt approach works only for apps, that do the special Qt dance.

kuschku 5y ago

Qt has done that for many years, so has Android, so has Windows. Only macOS and Gnome don't, because they value single-pixel alignment errors more than the massive performance issues and reduced sharpness their solutions cause.

vetinari 5y ago
And Qt after all those years does not work correctly in HiDPI. Not even on Windows. Unlike macOS and Gnome, which do.
- kuschku 5y ago
  Gnome does NOT work correctly in HiDPI. I’ve got 3 systems with 1.5x scale, and Qt handles them perfectly fine (even with per-monitor separate scaling). While Gnome absolutely does not. Either I get absolutely unreadable tiny 1x, or I get absolutely unusable 2x with no space for anything. (That said, Qt on Windows handles per-screen scale factors very weirdly, especially with applications using pixel values)
  - nextaccountic 5y ago
    In my screen, 1x and 2x are both inadequate, but I'm using Gnome on Wayland on 1.25 scaling right now. Gnome can do fractional scaling. You just need to configure it with a gsettings command: https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fractional-scaling.html https://www.linuxuprising.com/2019/04/how-to-enable-hidpi-fr... https://wiki.archlinux.org/title/HiDPI#Fractional_scaling https://wiki.archlinux.org/title/HiDPI#Fractional_scaling Or using gnome-tweaks. Then, on display settings, it should show up the new scaling configs. And, in Gnome it's very sharp, with zero blurring! It was somehow sharper than whatever KDE was doing when I tested it some months ago.
    - kuschku 5y ago
      Eh, no. Gnome doesn’t actually do fractional scaling – as said earlier in the thread, it’ll render at the next integer resolution and scale down in GPU. Which I don’t really have the performance for (I’m already using Budgie’s option to do exactly that under X11 right now already, it’s not exactly the most performant solution). And even under Wayland, Gnome still renders at the next integer scale. While KDE under X11 actually renders at the correct resolution, with proper scaling and perfect sharpness, which I really miss.
      - md8z 5y ago
        That is working as intended, and either you don't have a graphics card that is good enough to drive your monitor, or you're using CPU-rendered apps that will always be slow at higher resolutions. This is a problem with a lot of cheap hardware and older software. It worked for Apple because IIRC they've been porting all the low level drawing over to Metal. GNOME is a lot slower to do that unfortunately, you won't see everything being GPU accelerated until GTK4 becomes widely adopted.
        kuschku 5y ago
        That’s not what I, as mostly android/web/qt dev, want though. Why should I get 50% less performance just to fix some tiny single-pixel issues on a screen where I can’t even see individual pixels?
  - vetinari 5y ago
    The principial difference between how Mutter/Gnome and Plasma/ handles hidpi is, that for Mutter/Gnome it works for old apps without any modifications, while the Plasma/Qt approach works only for apps that were modified to use the new APIs. Yes, the old app on Mutter will be upscaled, but it will be right scale on each monitor in mixed-dpi environment. Yes, even that old wordperfect from 1998. While on Plasma, non-Qt apps will have hard time. Also, you won't be able to do perfecly fine anything on 150%. How are you going to do 1-pixel wide line? Exact cursor positions? You are not going to. With hw downscaling, yes, you pay the price for larger framebuffer and you get good approximations, but you also avoid a great deal of corner cases, that most software users are running is never going to solve.
    - kuschku 5y ago
      > Also, you won't be able to do perfecly fine anything on 150%. How are you going to do 1-pixel wide line? Exact cursor positions? You are not going to. With hw downscaling, yes, you pay the price for larger framebuffer and you get good approximations, but you also avoid a great deal of corner cases, that most software users are running is never going to solve. I care more about the performance loss of rendering at excessive resolution than about the 1-pixel imperfections. > that for Mutter/Gnome it works for old apps without any modifications, while the Plasma/Qt approach works only for apps that were modified to use the new APIs. You could do a hybrid approach and render old apps at 1x/2x and down/upscale them and let updated apps render at the native resolution. At least render fonts at native resolution and only up/downscale the rest of the widgets. Scaling fonts can NOT be done by post-processing or it WILL be wrong. (MacOS only scales widgets, images and fonts will always be rendered at native resolution)
      - vetinari 5y ago
        > MacOS only scales widgets, images and fonts will always be rendered at native resolution MacOS scales entire framebuffer. You can verify it by doing a screenshot and examining it.
- vetinari 5y ago
  For downvoters - exhibit A: https://imgur.com/a/Ad0ZkmX https://imgur.com/a/Ad0ZkmX Problems like this are common, it is not app specific. If you call this a superior solution, then you haven't seen a really working one.
  - Vogtinator 5y ago
    Looks like that application explicitly uses (device) pixel sizes. That issue is common, but still application specific.
    - vetinari 5y ago
      In that case, it is still the problem of the approach that Qt has chosen. With macOS or Gnome, even apps from 90's that were newer updated, will have proper scale. They might be blurry (macOS upscales using nearest neighbor so it is pixelated, Gnome uses bilinear, so it is blurry instead), but they will be correct size. The Qt approach works only for apps, that do the special Qt dance.