Display Scaling

> Would you mind to elaborate?

Well. Did you ever try to place two monitors with disparate (and possibly fractional) resolutions next to each other and have a window seamlessly stretch from one screen to the other?

Using X that's basically impossible. There simply is no way to shoehorn the ability to do this into X11. Each window is backed by a single bitmap with a predetermined resolution, period end of discussion.

With Wayland it's a no-brainer. It. Just. Works.

The flip side is that Wayland has to re-implement some of the *other* features that were a no-brainer under X. Different display paradigms and all that. A lot of work went into X over its lifetime and you can't replicate all of it instantly.

Not to mention: on top of that, somebody needs to write the code to support the new cool stuff that's now possible. Just one example: Say you temporarily need to add another screen to your computer but you don't have a free display output? Fine, let's dynamically add a headless display to the running compositor and show it on your laptop using VNC. Done.

Granted, writing code for new cool stuff is a lot more sexy than writing code for all the old boring usecases that we still need and like to keep working, and granted we could do without the Gnome vs. KDE vs. wlroots nonsense that accumulated during the transition. But we're getting there IMHO.

Oh, there's an unbelievable list of problems once you start even thinking about doing it properly. The sibling comment goes into some of the compositor problems, but it's just the tip of the iceberg.

So here's some things to just think about:
- Window moves from one display to another
- User has a window span multiple resolutions
- Two monitors of the same resolution, but different sizes
- Two monitors of the same size, but different resolutions
- The larger monitor is actually lower resolution.
- You drag a window from one monitor to another. Where does it appear and what size will it be. The obvious answer is physical size, right. But...
- ...it's a projector, TV or something else comparatively huge. What happens if you drag windows between them.
- Laptop gets suspended, gets plugged into a dock attached to a display, and wakes up with the lid shut i.e. primary display suddenly changes resolution. Where do the windows go now and how big should they be.
- Applications often clamp line widths to be exactly 1 pixel (and align them to pixels) to prevent weird rendering of thin lines and varying brightness caused by antialiasing. What do you do if there's two resolutions.
- The user has used the preferences to specify exactly how thick the lines should be and will be annoyed if it's ever wrong.
- Subpixel Rendering. Just everything to do with it.
- Respecting the system text size preferences well across applications, OSes and Toolkits.
- What you do and don't scale with the text size.
- The application might want to use different layouts and scaling depending on how much screen estate is available.
- You want to remember the size and position of windows across restarts, but the resolution has changed.
- Multi-window apps having to do all of the above at the same time across multiple monitors.
- One monitor gets unplugged or goes into standby. You better remember where and what size those used to be when it comes back. But those windows must also remain visible on the workspace. Bonus: What if the user moved the window in between. What if it's a different monitor. Do you pop up their sensitive browser window they forgot about on the office projector when it gets plugged in, because that's where they had it at home?
- Games, especially simulators, that want to work across multiple displays
- VR, just in general
- You want to implement the power saving feature that many phones have where they dynamically change the screen's render resolution (and hence dpi) depending on battery saving settings and the content of the display. But everything should stay where it is. This can not break any of the solutions to previously mentioned problems.
- Let's not forget various accessibility features like magnified views (they better not be pixelated, and it better not have to render the entire window at 32k to do it), people who need extra large text, people who need big buttons but want small text, etc.

Many of these can be solved if you're willing to dedicate most of a lifetime to them, for sure. But they're not the kind of problems you can just solve once and for all with a good design. It takes a lot of work to get a good coverage of most of the edge cases and a lot of tuning and heuristics at all levels of the stack that must play well together and nobody notices, until they're wrong.

There are also some bonus unsolveable problems though:
- Users generally want the contents of their displays to be big enough that every element has enough pixels, as small as possible to maximize screen space, but big enough physically to still be readable. What points those are depends on the person, their eyesight, device size, form factor, environment, etc.
- Applications all have their own, varying ways of adapting to various DPIs which were built to work exactly with the behavior that the developers assumed at the time and there's not really any way for compositor to figure out what those assumptions are.
- The perceived size changes depending on your distance to the object.

Have fun :)