Challange your knowledege, and take a quiz.Go to FOSS Quiz
There’s a special type of displays commonly called “HiDPI“, which means that the number of pixels in the screen is doubled (vertically and horizontally), making everything drawn on the screen look sharper and better. One of the most common examples of HiDPI are Apple’s Retina displays, which do come with their desktops and laptops.
However, one issue with HiDPI is that the default screen resolutions are too small to be displayed on them, so we need what’s called as “scaling”; Which is simply also doubling the drawn pixels from the OS side so that they can match that of the display. Otherwise, displaying a 400×400 program window on a 3840×2160 display will give a very horrible user experience, so the OS will need to scale that window (and everything) by a factor of 2x, to make it 800×800, which would make it better.
Fractional scaling is the process of doing the previous work, but by using fractional scaling numbers (E.g 1.25, 1.4, 1.75.. etc), so that they can be customized better according to the user’s setup and needs.
Now where’s the issue, you may ask? Windows operating system has been supporting such kind of displays natively for a very long time, but Linux distributions do lack a lot of things in this field. There are many drawbacks, issues and other things to consider. This article will take you in a tour about that.
Fractional Scaling on Linux
Normal scaling in GNOME has been there for a lot of time, I don’t even remember when it landed; You could easily switch into a 2x or 3x scaling any time you want. But the issue was that it doesn’t support fractional scaling (E.g 125%), so you would end up in a lot of cases in either too large or too small screen resolutions.
In GNOME 3.32, the developers have added an “experimental” support for fractional scaling. Sadly, there’s no option to enable that one in the control center, so you’ll have to apply the following command in the terminal to enable it:
gsettings set org.gnome.mutter experimental-features "['x11-randr-fractional-scaling']"
After that, if you head to the GNOME Control Center, you’ll be able to see both the 125% and 175% options now:
Everything looks nice so far. However, from my experiments, this experimental scaling is very buggy on GNOME.
The following video demonstrates how I no longer can launch Flameshot to take screenshots of my desktop. GNOME Screenshots tool does work, but I depend on Flameshot a lot in my workflow, and I can’t offer to miss that:
Some applications like Telegram and Steam do not scale good (Telegram does have an option in its settings to scale it up, but it doesn’t get scaled by the DE instantly), I don’t know if some workarounds exist for Steam or not:
Also, here’s a video demonstrating how changing the levels of brightness or volume while playing games can give an unacceptable experience (Notice how the screen lags and goes back and forth):
Aside from the issues mentioned, fractional scaling on GNOME works good. All the native GTK apps on my desktop scaled with no problem (Nautilus, Terminal, Gedit.. Everything).
In addition to fractional scaling, GNOME supports fonts scaling, which allows you to control the fonts size scale only, and you can set it for whatever value you like. From my experience, I had no issues with it:
I think that KDE has the best support for fractional scaling on Linux. While nothing is applied automatically out-of-the-box, fractional scaling support in KDE is stabilized. So you can simply open the KDE Settings and scale your display however you like:
Browse FOSS Post ad-free when you subscribe to PatreonBuy Some Coffee
Notice how you can choose some values like 1.1, 1.2, 1.3… Those values do not exist in GNOME’s control center, and in fact, as you will see later, not even in Windows 10. There’s just some fixed values like 125% and 175% there.
However, one drawback here is that Firefox on KDE doesn’t scale. Notice how small its components are compared with the other elements. I am not sure if this issue is only related to Firefox, or all other GTK applications for example:
Steam and Telegram were scaled with no problem. It was just Firefox who was having an issue. As a small workaround, I found a Firefox extension called “Zoom Page WE” that increases the zoom level on all website to whatever level you choose. So in this case, I used it to automatically increase everything to 120%.
I didn’t face any issues in Steam while playing a game and change the levels of brightness/volume, it’s just working.
The GNOME’s Wayland compositor does support the same scaling in Xorg. The KDE Wayland Compositor developers have been working on a solution for a while, and you can check their progress from GitLab.
It also sounds like Sway (Which is an i3-like compositor) does support HiDPI scaling so far. But I haven’t tested it personally.
Xfce doesn’t support HiDPI scaling, same is true for MATE (Which is normal since they written in the same GTK toolkit).
Fractional Scaling (HiDPI) Support on Windows 10
I have to admit that HiDPI support on Windows is the best one available in the market. In Windows, if the system detects that your display is actually too large in terms of pixels, then scaling will be automatically applied for you.
Just directly after installing a fresh copy of Windows 10, I noticed that the system is already set to a scale of 125%:
In comparison, notice how a normal 100% scale would look like:
There are some other options to choose from too, but it sounds like Windows can’t be tweaked into using some other manual values (E.g 135%), but I think those ones are quite more than enough for my display:
What’s actually nice on Windows is that everything scales with no issues too: Steam, Telegram, Firefox… Every single app you have will look just as expected. There’s no need to Google about “how to enable experimental scaling in Windows”, there’s no need to ask for help in solving the bugs afterwards… It just works automatically out of the box.
And Windows support for HiDPI isn’t something new like most Linux DEs. It has been available almost from the same time when those screens became available in the market. So the factor of availability of support is also important for the user. In GNOME, for example, the feature is still experimental.
You’ve seen how all of these working environments support HiDPI. It is fair to admit that having a multi-billion dollar company like Microsoft behind Windows is totally different than the small organizations or communities behind the famous Linux desktops, so of course the results are going to differ. Think of this article as as an explanation of the situation rather than pointing fingers to someone.
However, the progress is great so far, and we are almost there!
We hope this is going to improve by time.