Individual GNOME applications

Posted Jun 25, 2025 8:38 UTC (Wed) by patrick_g (subscriber, #44470)
In reply to: Individual GNOME applications by ebee_matteo
Parent article: GNOME deepens systemd dependencies

> Certain things like HiDPI and multiple monitor setups that are expected by modern users are very difficult to add to X11

How can we be sure it's true? Have you seen that post from Ted Unangst?
https://flak.tedunangst.com/post/forbidden-secrets-of-anc...

Individual GNOME applications

Posted Jun 25, 2025 8:48 UTC (Wed) by pbonzini (subscriber, #60935) [Link] (5 responses)

The problem is having mixed resolutions, stuff at one high DPI external monitor and a low DPI laptop screen. Bonus points for rendering at one resolution and zooming to the other when a window is moving between one screen and the other.

Individual GNOME applications

Posted Jun 25, 2025 10:06 UTC (Wed) by smurf (subscriber, #17840) [Link] (4 responses)

For even more fun, try a window that spans both screens. Doesn't work: depending on the phase of the moon you either have a half window that's way too large, or one that's way too small.

This is a fundamental X11 protocol limitation.

Granted that you could "fix" this by creating a virtual high-res screen that replaces your low-res one, then downscale onto the latter, but (a) the result looks somewhere between ugly and unusable if you want do to Real Work, (b) we're way beyond the point where the heap of hacks and extensions that has been piled onto the original X11 protocol stopped being maintainable in a meaningful way.

Individual GNOME applications

Posted Jun 25, 2025 12:37 UTC (Wed) by dskoll (subscriber, #1630) [Link] (3 responses)

I have an X11 setup with four monitors, and I can move a window so half of it is on one monitor and the other half on another and it works just fine. Perhaps I am not quite getting what you mean when you write "try a window that spans both screens."

Individual GNOME applications

Posted Jun 25, 2025 13:29 UTC (Wed) by farnz (subscriber, #17727) [Link] (2 responses)

If you have different scale factors for each screen, so that windows appear the same size as they cross the boundary even though the screens have different native PPI, you'll see the issue on X11, but not Wayland. You won't see this with 4 monitors of same diagonal size and resolution.

Under X11, the display is represented as a single large buffer, rectangular sections of which are sent to scanout. Scaling is applied to content as the window content goes from the application's internal representation to the buffer, and this scale factor is the same for all monitors (whether that's the 200 PPI laptop display I'm using as a second screen, or the 150 PPI external monitor I use as my primary display). As a result, I cannot set a scale factor that's right for both monitors - there will always be a discontinuity at the seam, because X11 assumes that something 1,000 pixels high on my laptop screen is visually the same height as something 1,000 pixels high on my external screen, and that's not true (on my laptop screen, that's about 5 inches, on my external screen, it's a bit over 6.6 inches).

Wayland's architecture works differently; the display is considered as-if it's composited from individual windows at scan-out time. The compositor and the application negotiate the window's scaling factor, so the application knows that it's rendering something that's visually meant to be 1,000 abstract units high, but that it's being expected to render (say) a 2,000 pixel high buffer that will be scaled down by the compositor. The compositor can then scale that down to 1,500 pixels on my external monitor (10 inches), and display it at 1:1 on my laptop screen (10 inches), making it look the same on both monitors.

Wayland can also renegotiate the scaling as windows move; so when a window is on my external monitor only, the application can know that it'll be rendering a 1,500 pixel high buffer, which will be rendered as-if it filled 1,000 abstract units of space, while moving that window to my laptop screen gets the same application told to render to a 2,000 pixel high buffer, which will be rendered as-if it filled 1,000 abstract units.

Individual GNOME applications

Posted Jun 25, 2025 15:00 UTC (Wed) by paulj (subscriber, #341) [Link] (1 responses)

Hmm... the thing is, you can still change the resolution on external monitors to suit. You don't per se need to have Linux do the scaling.

The only time I notice scaling issues now is with xpra to apps running on a server and I havn't set dpi to 48 with xrandr. It doesn't seem to affect any local apps on the HiDPI laptop, but scaling of /1/ particular app (which seems to use some custom toolkit in Java that renders via OpenGL) can be off. Other than, things have been fine for years, with my HiDPI laptop and the monitors I plug into anyway (1 of which is one of those large, v wide Dell ones).

Individual GNOME applications

Posted Jun 25, 2025 15:12 UTC (Wed) by farnz (subscriber, #17727) [Link]

Well, depends on the display and the attachment method; my external monitor flickers wildly at any resolutions other than CEA-861 predefined resolutions (and I've not bothered to work out why - there's a firmware update available, but I'd have to get a Windows machine sorted to apply it). No trouble at 640x480, 2880x576, 1280x720 or 3840x2160, but huge trouble at 2560x1440@60Hz. I therefore need Linux to do the scaling, because the scale I'm asking for would need the monitor to run at 2560x1440.

And I also find that Linux is better at doing the scaling than the monitor is; text is easier to read when the application renders for a 5120x2880 monitor, and then the compositor downscales to 3840x2160, than it is when the application renders for 2560x1440, and the monitor or the compositor upscales to 3840x2160.