Edit: The decision to use integer coordinates I believe was made long ago in GTK1 because that's what X11 used, and it just hasn't been changed since.
"Especially since with X11 it was at least somewhat possible to do it"
X11 never actually supported this and also only uses integers for screen and input coordinates so I'm not sure what you're referring to. I think you are thinking of the app itself doing its own DPI scaling which will also work in wayland, but it will have the same problems where the DPI could mismatch with other apps and with the rest of the desktop.
"I’d love to help extending wayland, deprecating GTK3 and GTK4"
Well GTK3 is already in maintenance mode, and apps are currently in the process of being ported to GTK4, so first they'll probably want to finish that and get some feedback before starting on GTK5... it will probably be at least a few years before anything related to this could ship.
GTK2 could actually render at 144dpi, or 108dpi, just fine. Everything was slightly misaligned, not everything scaled perfectly, but it worked.
X11 had an integer Xft.dpi variable. Wayland now just has an integer scale variable.
WHY was this downgrade made? If a protocol break could be made to remove this functionality, a protocol break to add it back should be just as justified.
Break everything, apparently removing functionality was a good enough reason to do it, re-adding it should be just as well.
Yes, I am extremely angry after having spent years yelling at the wayland-wg and gnome devs not to make these decisions, not to put these things into the protocol, and complaining that if an API break is necessary, it should be extensible for these use cases. I’ve been complaining for a decade now and all of the complaints got ignored and instead the mistakes I warned about were made.
I understand your frustration but from what I have seen, nothing has actually been removed. This is just a feature that was never implemented because nobody signed up to implement it. Wayland could be extended to support it eventually but somebody actually has to put in the work. I think the best bet for somebody working on this would be to get it fully working and stable in KDE first, since Qt apparently has the toolkit support for it, and then maybe it can be adapted to work for GTK.
The issue with that is that first of all, the wayland protocol needs to be modified to add support for this, and the entire freedesktop/gnome community refuses to even consider adding support for anything like this because gnome doesn’t need it/can’t support it.
I’ve talked with vendors of devices using Linux with Wayland, who’ve been trying to get the committee to add support for years.
I’ve talked with KDE devs who’ve been frustrated without limits.
There’s a lot of people who are absolutely burnt out and angered by the constant stonewalling from Gnome, pretending for a decade that no one needs this and so it shouldn’t even exist.
Once they become stabilized and if other desktops took an interest, then they could be proposed as standard. But KDE does not need to wait for GNOME to implement a feature in Wayland, or vice versa. If you could mention which KDE developer you were talking to then maybe we could help them get this implemented in KDE first? Then afterwards if they can offer some tips to offer GTK (or other toolkits) on how to implement this, that would be valuable to everyone.
Sure, Gnome still won't adopt them ever because they're stubborn and think they know everything better, but at least I'd have a somewhat working solution.
Maybe elementary OS would actually use it too, they've already got support for just scaling everything based on the font size.
Thing is, I need this functionality yesterday. And it's been an absolute pain hearing that even if you spend an excessive amount of work today, in a community where all of gnome is against you, maybe someday in a decade it'll get better.
As long as Gtk refuses to support this, I can fix KDE, but I can't fix Java or browsers.
Java, Firefox and Chrome reject patches, saying Gnome is responsible. Gnome says they don't care.
And I don't want to run custom builds of Firefox and Java anymore. It was such a hassle constantly building them from source with my old patchset.
If you are really committed to using Linux and don't want to wait then I said it before but I think a better use of your time would be to spend a few hundred dollars on some different monitors that can work at just 2x scale, and then let someone else deal with this.
Usual price point around $1600-$2200.
Comparable 2× monitors start at around $4500, and the cheapest option only supports macOS and has a $1000 monitor stand.
A "few hundred dollars" won't be enough.
At the moment, I just work all day at ~10-15fps using Budgie with fractional dpi on X11, but it's definitely not a great experience.
I used to be 100% in on KDE, but as you mentioned, Wayland support is limited.
Budgie is atm sadly the only option for multi-monitor hidpi that's not using gnome's broken top bar concept.
That said, 10-15 fps on X11 is a pathological case, something is wrong there. When I ran X11 and played with xrandr, the slightly larger framebuffer had zero impact (outside games) on AMD Vega64.
Your definition for just fine must differ from everyone's else. Most GTK2 shipped assets for 96 dpi and that's it. Just try running GIMP on 192 dpi display, with "properly set dpi", for example. You will see yourself that is was not just fine.
> WHY was this downgrade made?
Because it didn't work. That's why.
> If a protocol break could be made to remove this functionality
It wasn't protocol break. It was apps either ignoring the facilities (in better case) or being outright broken -> desktop locking on constant values, where everyone was able to test their wares.
> protocol break to add it back should be just as justified.
Not going to happen.
> Break everything, apparently removing functionality was a good enough reason to do it, re-adding it should be just as well.
You can start. Show 'em.
I have.
I’ve made a custom build from source of my entire desktop environment, changing the scale factor back to a dpi value, and modifying Qt and Gtk2 apps to use that.
And it works.
You just need to break the wayland protocol and rebuild everything from source, but for over 2 years, I ran that as daily driver setup because I was so pissed off by this decision.
You don't get to modify apps -- that's exactly part of the problem being solved; your solution has to work with whatever user throws at it; from Chrome to xeyes, sorry.
Oh, and with staged updates too -- it might take some 2 years to adopt your solution, if everyone cooperates (which is a big if); not all distros update at the same time and some do not bother updating for another cycle (see Ubuntu and Wayland).
That's not how open source works. We get to modify apps. That's the whole point.
1) people are running all kinds of applications on Linux, not just open source ones. The solution has to work with Siemens NX or Autodesk Maya just like it works with Gtk Demo.
2) Even if you can modify apps, are you going to modify them all? No, most of them would be never fixed.
3) so you are mistaking "we get to modify apps" with "we get to rebuild the world, and everyone's system is part of the rebuild".
Applications which are extremely performance critical and accuracy-critical, where the compositor shouldn’t touch rendered pixels at all? Yeah, that works great, right?
We can just enforce the functionality in all new toolkits and deprecate old ones. Existing, old software will just render badly, like it does today, and everything new or updated will get all the advantages.
We can even enforce a new Wayland2 protocol, everything old can just render through XWayland as a blurry mess, Gtk3/4 included (they do support X still after all), and everything new can use the improved protocol immediately.
Edit: For further explanation see here for a longer description of GTK's release strategy. https://blog.gtk.org/2016/09/01/versioning-and-long-term-sta...
So, I have to use linux.
And I have to use something which supports my 27" 4K monitor at 1.5x scale today, not at some point in the future.
I can’t just not work until this is fixed, I have to deal with what broken tech exists today. Sadly.
Your new API won't be adopted by everyone overnight, that's why it is a dead end.
GTK3 is the exception but you can just let it be blurry; everything else can be sharp.
One of the issues in X11 is, that the display server can tell the clients what the screen dpi is, but it never knows, whether they honor it -- and they never tell. Many of them don't, some do, so you cannot have uniform handling for them, and if you find a mechanism where they can tell, how do you retrofit it back? You won't.
So yes, putting the mechanism into current toolkit is easy, but that means that the linux desktop is going to be broken for decades to come, because the old client won't disappear overnight. If they did, we would be in pure Wayland for years already...
Exactly. Nobody is going to update everything what's already out there. For many things, there's not even the source, even if there was a will. There's unbelievable dragging of the feet in the Linux community, so even that will is a big question.
These compositors have to play with cards they were dealt, not with cards they wish they had.
I’ve complained about this since before Gtk3 and Wayland were stable, constantly warning against making these decisions, and now that the bad decisions have been made, doing another protocol break to fix them is apparently out of the question?
When GTK3 came, it didn't break GTK2 and GTK2 apps. They could work side-by-side, as they were before.
What you suggest is either kicking out the world from beneath them, or having all of them updated, at the same time.
That's not going to happen.
It’s absolutely possible. And as mentioned, switching from dpi as int to scale-factor as int was reason enough to break all software, going back should be just as justified.
The same can be done in any environment where the protocol between toolkit and compositor contains enough metadata and applications can tell the compositor that they’re rendering at native scale.
So, X11 works, Wayland won’t work until the protocol gets significantly changed.
I had a similar patch for my compositor, the protocol libs, and Qt where I just let windows specify that they’re rendering at native scale, and I let Qt handle the scale factor as if QT_SCREEN_SCALE_FACTORS had been set accordingly.
And then you’d need a way for applications to tag each buffer it renders with the DPI it’s rendered at, so the compositor can show the right buffer natively on the right screen.
For performance improvements, it even makes sense to provide a clip mask telling which part of the window each DPI should be rendered for.
Now, that’s complicated, but doable. I did it.
What’s more complicated is handling situations where compositors don’t support this, or only support parts of it.
That whole backwards compatibility part is more work than getting the whole feature built and shipped, and it’s entirely unnecessary.
Edit: Also I'd like to give some feedback.
"a way to have the compositor notify the application which dpis it should render at (because it’d be multiple)."
Right, so that's one additional message. I assume by multiple you mean the case when you have multiple monitors at different scales.
"a way for applications to tag each buffer it renders with the DPI it’s rendered at, so the compositor can show the right buffer natively on the right screen."
I think this would be one or two additional messages. But I'm actually confused by why you would do this because it seems like it would still cause performance issues, if you're now rendering every program two or more times every frame. I think you may want to save this for an "accuracy mode" or something, and normally have it so only the max DPI applies.
"it even makes sense to provide a clip mask telling which part of the window each DPI should be rendered for"
This won't work in Wayland because the client never clips windows, it just redraws the whole window each time.
"What’s more complicated is handling situations where compositors don’t support this, or only support parts of it. That whole backwards compatibility part is more work than getting the whole feature built and shipped, and it’s entirely unnecessary. "
I don't see how that's complicated or why it's more work, programs would just work as they do now, i.e. you just assume those programs always have a DPI of 96 * buffer_scale.
Also depending on how you design this, you may have to consider how this would interact with OpenGL and Vulkan, and maybe consider the possibility of creating additional extensions there in order to handle this. But that may or may not be necessary, I'm not sure.
Some compositor/toolkit combinations today render at both 1x and 2x, or similar scales, if multi-monitor setups are used.
Now, to improve that situation, you’d need to render at each of the scales of the monitors the window is on right now instead.
To improve performance of that, sending a clip mask from compositor to toolkit to say "hey, only render the left half at 2x, right half at 1x" makes sense, if the toolkit decides to support it, that’d improve performance at no cost.
> or only support parts of it
What if the compositor sends the info about each monitor’s DPI, but doesn’t support the dpi-tagged buffers, instead only supporting viewport-tagged or integer-scale-tagged buffers?
And the windows solution is not reliable either; the only reliable solution was macOS one.
I’ve got all my time already full with jobs, projects, and other stuff I’m working on, if I’d find time, I’d love to help extending wayland, deprecating GTK3 and GTK4, and modifying the software accordingly.
I’ve made custom patches for the same purpose in the past already, but I just don’t have the time.
Especially since with X11 it was at least somewhat possible to do it, but now with wayland it’s sadly enforced in the protocol to only use 8-bit sRGB and integer scale factors.
If I ever find the person responsible for that decision...