9 ms·

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 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.
        md8z 5y ago
        I think you might be thinking of Cairo when used with one of the print backends, not GTK. GTK2 did not use float coordinates or support fractional rendering. See for example here: https://developer-old.gnome.org/gtk2/2.24/GtkWidget.html#gtk-widget-set-size-request https://developer-old.gnome.org/gtk2/2.24/GtkWidget.html#gtk... https://developer-old.gnome.org/gtk2/2.24/GtkWidget.html#gtk-widget-queue-draw-area https://developer-old.gnome.org/gtk2/2.24/GtkWidget.html#gtk... Those would need to be floats if you wanted to have a non-integer scale. Changing everything to use float coordinates is a large undertaking that touches the whole stack and will require a lot of work. It still hasn't been done yet as of GTK4. If you'd like to spend your time helping out then please do so. Please refer to the gitlab comment above for a description of some of the technical issues that you would have to solve. But it may be more cost effective for you to just get some new hardware with a better GPU, or use something else.
  - vetinari 5y ago
    > Gnome doesn’t actually do fractional scaling Gnome actually does fractional scaling. It doesn't do fractional rendering. Two different things; you can do one without another. As I wrote elsewhere, you cannot do perfect sharpness at fractional resolutions. How are you going to render 1px wide line exactly?
    - kuschku 5y ago
      > As I wrote elsewhere, you cannot do perfect sharpness at fractional resolutions. How are you going to render 1px wide line exactly? With downscaling, I get a blurry mess. With fractional rendering, I get a line that may be a tiny bit too wide or too thin, and may be one pixel off, but it’s going to be perfectly sharp and clear. 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.
      - vetinari 5y ago
        > 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. They are fine, but just cannot downscale to arbitrary sizes. Note that macOS doesn't do 125%, for example, because that's one of the worst cases - you have 5 pixels to do job of 8.
        kuschku 5y ago
        If you do that, you throw out all the hinting and scaling code the font authors may have added. Many fonts intentionally change weight slightly at small sizes, by scaling it afterwards you break this functionality. Also, by scaling afterwards in compositor in sRGB space you create issues with brightness as the compositor (at least under Gnome) does not take gamma into account. The amount of tradeoffs is extreme, compared to a few UI widgets getting slightly shifted around. And I’ve already mentioned the performance issue in multiple other places in this thread.
        5y ago
  - nextaccountic 5y ago
    I mean, it works, and the end result is a fractional scale. But, yeah, it has some overhead. When I tried here some months ago, KDE with fractional scaling wasn't as sharp as Gnome's upscale-then-downscale (I'm not really sure why. Downscaling should involve some blurring). I really wanted to use KDE, but text rendering on KDE's fractional scaling appears to be blurry.
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.

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.
        md8z 5y ago
        I think you might be thinking of Cairo when used with one of the print backends, not GTK. GTK2 did not use float coordinates or support fractional rendering. See for example here: https://developer-old.gnome.org/gtk2/2.24/GtkWidget.html#gtk-widget-set-size-request https://developer-old.gnome.org/gtk2/2.24/GtkWidget.html#gtk... https://developer-old.gnome.org/gtk2/2.24/GtkWidget.html#gtk-widget-queue-draw-area https://developer-old.gnome.org/gtk2/2.24/GtkWidget.html#gtk... Those would need to be floats if you wanted to have a non-integer scale. Changing everything to use float coordinates is a large undertaking that touches the whole stack and will require a lot of work. It still hasn't been done yet as of GTK4. If you'd like to spend your time helping out then please do so. Please refer to the gitlab comment above for a description of some of the technical issues that you would have to solve. But it may be more cost effective for you to just get some new hardware with a better GPU, or use something else.
- vetinari 5y ago
  > Gnome doesn’t actually do fractional scaling Gnome actually does fractional scaling. It doesn't do fractional rendering. Two different things; you can do one without another. As I wrote elsewhere, you cannot do perfect sharpness at fractional resolutions. How are you going to render 1px wide line exactly?
  - kuschku 5y ago
    > As I wrote elsewhere, you cannot do perfect sharpness at fractional resolutions. How are you going to render 1px wide line exactly? With downscaling, I get a blurry mess. With fractional rendering, I get a line that may be a tiny bit too wide or too thin, and may be one pixel off, but it’s going to be perfectly sharp and clear. 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.
    - vetinari 5y ago
      > 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. They are fine, but just cannot downscale to arbitrary sizes. Note that macOS doesn't do 125%, for example, because that's one of the worst cases - you have 5 pixels to do job of 8.
      - kuschku 5y ago
        If you do that, you throw out all the hinting and scaling code the font authors may have added. Many fonts intentionally change weight slightly at small sizes, by scaling it afterwards you break this functionality. Also, by scaling afterwards in compositor in sRGB space you create issues with brightness as the compositor (at least under Gnome) does not take gamma into account. The amount of tradeoffs is extreme, compared to a few UI widgets getting slightly shifted around. And I’ve already mentioned the performance issue in multiple other places in this thread.
        5y ago
- nextaccountic 5y ago
  I mean, it works, and the end result is a fractional scale. But, yeah, it has some overhead. When I tried here some months ago, KDE with fractional scaling wasn't as sharp as Gnome's upscale-then-downscale (I'm not really sure why. Downscaling should involve some blurring). I really wanted to use KDE, but text rendering on KDE's fractional scaling appears to be blurry.

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.