Blurry text when using Sway or fractional scaling on Wayland Follow
IntelliJ IDEs - like other Java applications - use X11 to talk to the Xorg server and render on Linux. When running on a desktop with Wayland (like Ubuntu 21.04), Java actually continues to work through X11, but this time the Xorg server is implemented by XWayland, providing a migration path for the applications that don't (yet) use Wayland directly.
Without fractional scaling enabled, XWayland simply lets X applications render the same way as under "pure" Xorg suggesting the desired DPI through the Xft.dpi X resource value. In this configuration, text is rendered as sharp as under “pure” Xorg.
When using Sway or with the fractional scaling enabled, any scale above 100% - fractional or not - reduces the screen size available to X applications proportionally. For example, this is what an X application sees with "fractional" scaling of 200%:
$ xrandr --current
Screen 0: minimum 16 x 16, current 1280 x 800, ...
and this is with the same scaling of 200%, but fractional scaling disabled:
$ xrandr --current
Screen 0: minimum 16 x 16, current 2590 x 1664, …
As you can see, the screen size with fractional scaling is roughly twice as small. So in this mode Wayland provides a smaller screen to X windows that are then pixel-stretched according to the system's scaling factor. This makes the window's contents look somewhat blurry, which is most noticeable with text. The effect can be seen with any "pure" X application like XTerm, for instance.
Many applications have already been ported to use Wayland, either directly or through a toolkit like Gnome. Java is on its way to be ported. The Wayland rendering pipeline project has just started (see the announcement) and JetBrains has joined this initiative.
Until Java has learned to use Wayland natively or until the fractional scaling feature of Wayland is reworked to avoid pixel-stretching X windows, workarounds for blurry text would be to
- when using Sway, switch off scaling completely
- switch off fractional scaling ([link1] [link2]) or
- go back to using "pure" X session without Wayland ([link]).
- JBR-3206 Native Wayland support
- GNOME Mutter issue: X11 apps on Wayland don't scale on hidpi, sharp on X server
- Sway issue: Disable scaling of xwayland applications
- OpenJDK Wayland project announcement: Call for Discussion : New Project to support the Wayland display server on Linux
- About the fractional scaling feature in GNOME 3.32
- JetBrains support: HiDPI configuration
Please sign in to leave a comment.
Summary: If you have a 4K screen that is usable at 200%, do not enable fractional scaling. Use the 200% option without fractional scaling.
If you have multiple monitors and only one of them is hidpi, the JetBrains IDE must be launched on that monitor. This is the trickiest part.
The actual summary is that you can't use JetBrains IDE's with fractional scaling enabled. There is no 200% option that isn't fractional scaling. This is the one thing preventing me from moving to Wayland, because other applications (browsers) do not scale well with the "200% option", only the views change- none of the toolbars or menus change, including tab size.
GNOME is the most popular desktop environment on linux. Ubuntu, Fedora and Arch all default to Wayland when using GNOME. Fedora and probably more also default to Wayland with KDE. High DPI monitors are very common these days, making fractional scaling a necessity.
From this it seems to follow that a large majority of linux users would be affected by this. I think JetBrains should fix this ASAP.
Personally, I have two 27 inch 4k monitors. Both 100% and 200% scaling are unusable. The blurriness is very pronounced, resulting in a terrible experience.
I can hardly believe that the developers of Java only "just started" porting Java to Wayland in 2022. This should have started a long before this. I mean, I am not a Linux geek or anything, but even I had started using Wayland back in 2020 or 2019. Java is a popular platform that many large companies use, so I guess it was not that they did not have enough funding to for this, but maybe desktop applications are a second-class citizen in the Java world?