[loxias]

Ah, I think I get it. You want to use a "point" abstraction, not a "pixel" abstraction, right?

In your example, I imagine everything would work just fine, but images will be physically bigger on the 70 DPI monitor because, well, the pixels are bigger. I'm guessing that Wayland adds a layer of indirection, resampling the framebuffer based on the DPI to preserve the same point size across displays with different pixel sizes.

I ascribe to "the end user is always right" philosophy, so, if you want that functionality, you should be able to have it. But I wonder how popular that desire is. It's far from universal.

Personally, I find resampled images to be so distracting and distasteful that it makes a computer hard to use for more than a few minutes. I hate fuzzy text, fuzzy windows, and fuzzy pixels. Any time I've been forced to use a device at something other than its native resolution, I've gotten preoccupied with "how can i fix this ugly crap" until I get native resolution working, and I'm sure I'm not alone.

It's cool that Wayland does that for you, because you want it, but consider that to others, it might be a bug, and not a feature. :)

[hollerith]

You are incorrect in your belief that a modern Linux graphical stack centered on Wayland ever resamples or interpolates a virtual or actual framebuffer except for compatibility with apps that have not been adapted for Wayland. (Those apps use something called XWayland, which is blurry if the user has configured a non-standard size for things.) 99.9% of fonts these days, most icons provided by the OS, and most other graphical elements (e.g., rounded corners) are specified as mathematical descriptions of curves that can be rendered at the display's native resolution regardless of what size the user chooses them to be. (I believe the 0.1% of fonts that are not mathematical descriptions of curves are called bitmap fonts.)

Note that I am not talking about multiple displays, but rather a single display, but the user wants things to be bigger than they are by default.

I know this because have used all 3 major operating systems recently (MacOS, Windows 10 and Linux/Gnome) on plain-old 96-DPI monitors such that if there were any interpolation or scaling algorithm I would be able to see the effects.

On a monitor 1680 pixels wide, Gnome gives me a choice of the scaling factors 100%, 125%, 150%, 175% and 200%. On a monitor 1920 pixels wide, Windows 10 gives me a choice of the scaling factors 100%, 125%, 150% and 175%. Some apps are blurry as hell, but on both Windows and Gnome I was able to live my life using only those apps that don't have the blurriness problem, but then I am not forced to use old Windows apps provided or specified by my employer and don't need to share my screen (which I am told does not work yet on a pure-Wayland set-up like mine).

On Windows 10, I used Google Chrome, some apps such as Settings and Timer provided as part of the OS and VS Code. On Linux I used (and continue to use) Google Chrome, modern Gnome apps and Emacs. On Linux, I need to open Chrome with specific flags to get it to be non-blurry while the visual elements are a non-standard size, and I need an Emacs built from a git branch called feature/pgtk. Both apps have some bugs when used in this way, but the bugs are definitely live-with-able, and I expect the bugs to be fixed eventually.

[enriquto]

> You are incorrect in your belief that a modern Linux graphical stack centered on Wayland ever resamples or interpolates a virtual or actual framebuffer except for compatibility with apps that have not been adapted for Wayland.

This can be true only if you use a really narrow definition of "apps adapted for Wayland". For example, a viewer of png files may not be possible to adapt to wayland? A png file is just an array of pixels (typically without a meaningful dpi). How are you going to ever display it without interpolating and resampling?

[perth]

Yeah. I suppose this functionality isn't everyone's cup of tea. The cool thing about Wayland though is somehow it makes the windows still look crisp and good while making them the same size. With the canonical hack to xorg, they always looked blurry and gross. The gnome wiki had this to say on it:

"On a Wayland display server, each connected monitor will have a scale that depends on the DPI. A scale affects the scale clients draw surface contents when they are visible on said monitor."

So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image.

[destructionator]

> So it seems like it actually modifies the drawing at the application level rather than rescaling it like an image.

X also supports exactly this. Qt uses this information. gtk doesn't for whatever reason, forcing the workarounds.

Most the so-called "X limitations" are actually just toolkit bugs if you get into the weeds.

[md8z]

GTK doesn't support it because nobody implemented it. IIRC the Qt support is also pretty buggy and doesn't work on some compositors.

[danachow]

Then what is your complaint? No one is stopping you from using X for as long as you like. Meanwhile the majority of users that want sane, modern handling of HiDPI can move on.

[loxias]

> Then what is your complaint?

What complaint? Why do you think I'm complaining? I wanted to know what's so fundamentally wrong with X to warrant a massive developer effort to replace it.

Based on the comments here, I have my answer: Nothing's wrong with X. Also, something lighter weight is desired for embedded platforms.

Some fraction of the population, like you, wants their display system to render in terms of points, not pixels. To me, and many others, this would be hell, but hey, different strokes for different folks -- good software does what the user wants, not the developer's will.

> ...majority of users that want sane...

You troll. :P I think the majority of users want sane display systems that don't resample and change resolutions away from the native resolution of the hardware. To you, the majority of users want fuzzy text and ugly UIs. We're both wrong to assert this as some obvious fact, because neither of us speak for any user but ourselves!

If I have any complaint (which, again, I'm not sure if I do!) it's that I don't appreciate my reliable computing setup breaking just because some young developer decided the programs I use are "too old".

[arein3]

if you buy a high pixel density display (ex a 15 inch laptop with a 4k display) then you need to be able to map 2 real pixels to 1 logical pixel (what apple did with retina displays)

[wander_homer]

And this works perfectly fine already with X11. You only encounter issues when you add an additional display with different DPI. But dual monitor setups are the exception, and mixed DPI setups are even less common.

[danachow]

Mixed DPI setups are very common. A Retina Mac getting docked to external monitors of different DPI is tremendously common all over the place. Ironically on the Windows side I see tons of non HiDPI laptops that end up docked to higher DPI external monitors, but the other direction isn’t exactly rare either. Even if you don’t use those monitors simultaneously - this is still mixed dpi for all the apps that are currently running.

This does not work smoothly at all in X11. This is a mixed bag with Windows because of reasons that are well documented. The compromise chosen by Apple works reasonably well.

This is not about my personal preferences unlike the GP asserts, it’s based on observing hundreds of deployments in industry and academia - which both Apple and Microsoft are very much aware of - they don’t try to support these features for no reason at all. I personally don’t love the scaling done by Mac OS, and in an ideal world apps would just magically scale geometry and “do the right thing”, but that is a fantasy land and the best FLOSS unix has to offer with X11 does not meet a lot of users needs.

As for nothing wrong with X? Lol this is a display system that still does not have a sane unified way to prevent screen tearing - despite 30 years of shitty attempts.

[md8z]

Not really, you will probably have to deal with this any time you connect your laptop to a projector.

[kaba0]

That’s why eg. Macs default to integer-only scaling. But using them at 1x will make everything unusably small.