4 ms·

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?
        md8z 5y ago
        I'm not sure how to answer that question, you don't have to do anything you don't want to do. GTK and its apps currently use integer coordinates, so in order to change that it needs to be changed to use floating point, and all the apps need to be changed to use it too. This is an API break and another thing that will take a long time to plumb through the whole stack and I doubt it will happen until at least GTK5. Maybe use KDE or Windows until then? Or get different hardware? Edit: comment from a GTK developer here that goes more into detail: https://gitlab.gnome.org/GNOME/mutter/-/issues/478#note_793963 https://gitlab.gnome.org/GNOME/mutter/-/issues/478#note_7939... I guess if you want to know why should things be this way, you could say it's because of technical limitations? Though that may not be a satisfying answer to you.
        kuschku 5y ago
        GTK2 used float coordinates and supported fractional rendering. GTK3 breaking that is a bug, not a feature. Especially text should NEVER be scaled after rendering. And re: performance, that’s great that you’ve got hardware that can run 3D in-browser shader sites or games at 6K resolution at 60fps just fine, mine can’t. If it were running at 4K, as it’s supposed to, I’d get significantly more fps. Especially at a time where GPUs are rare and Gnome still decides I should get 50% more performance just so they save some work.
- 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.

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?
      - md8z 5y ago
        I'm not sure how to answer that question, you don't have to do anything you don't want to do. GTK and its apps currently use integer coordinates, so in order to change that it needs to be changed to use floating point, and all the apps need to be changed to use it too. This is an API break and another thing that will take a long time to plumb through the whole stack and I doubt it will happen until at least GTK5. Maybe use KDE or Windows until then? Or get different hardware? Edit: comment from a GTK developer here that goes more into detail: https://gitlab.gnome.org/GNOME/mutter/-/issues/478#note_793963 https://gitlab.gnome.org/GNOME/mutter/-/issues/478#note_7939... I guess if you want to know why should things be this way, you could say it's because of technical limitations? Though that may not be a satisfying answer to you.
        kuschku 5y ago
        GTK2 used float coordinates and supported fractional rendering. GTK3 breaking that is a bug, not a feature. Especially text should NEVER be scaled after rendering. And re: performance, that’s great that you’ve got hardware that can run 3D in-browser shader sites or games at 6K resolution at 60fps just fine, mine can’t. If it were running at 4K, as it’s supposed to, I’d get significantly more fps. Especially at a time where GPUs are rare and Gnome still decides I should get 50% more performance just so they save some work.
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.