The issue seems to be on both sides. SDL, mpv and etc. don't want to depend on GTK, but it looks like Mutter developers don't want to do that either. The end result is very messy.
Unlike Mutter, KWin for instance does depend on Qt, and provides server side decorations which allows such non GUI windows easily draw minimal controls and the title bar.
Rasterman, of the Enlightenment wm fame, also wrote about this, and he holds the same opinion as Gnome folks. He also noted, that other OS-es (i.e. Windows and macOS) also do client-side rendering. You just don't get to choose, whether you will link the library doing that, when it is required to open the window surface in the first place.
I still tried to use it for a couple of months, but the performance difference is quite noticeable.
And doesn't need to be C or C++, anything else that compiles to native code AOT would do as well.
Script kiddies writting GNOME extensiosn with 100% CPU use and memory leaks?
As for safety, yes C++ and specially C are quite good at memory corruption bugs. Which I am quite aware, if you look at my comments history.
Exactly because of that I took care to expressly mention "And doesn't need to be C or C++, anything else that compiles to native code AOT would do as well.".
My favourite tiling WM is awesome, and the majority of the interesting functionality for that is scripted in Lua, which is fast but more of a niche language.
However, awesome doesn't support Wayland, and the awesome-clones for Wayland are all early-development and don't work very well for me.
GNOME supports wayland, has session management, styles things consistently, has sensible defaults, and thanks to the JS engine and the extensions repo, can do exactly what I want it to do.
(Except for those !£$"£$% gigantic title bars which GNOME apps like to stuff navigation things into so you can't really remove, wasting SO much screen estate....)
The point of the gigantic titlebars and widgets in GTK3 is to support touchscreens - you can "grab" the big titlebar on a touchscreen and move the window easily, which you wouldn't be able to do with traditional window decorations. Once you're constrained to a bigger titlebar, having widgets in there as well is just sensible. Windows 10 has chosen the alternative of just making the titlebar thicker without stuffing anything in there, which wastes more screen space! (I still think there should be a traditional, mouse-oriented layout for systems which don't support touch-- but guess what, that's quite hard. The default should be touch-friendly.)
No, but really, saying things like "I hate the technical decisions made by your project, please change it" without really participating in the project is silly. It is like "why not Rust?" all over again.
So your explanation, while common amongst Linux devs, is a rather cheap cop-out in comparison to the bigger two competitors who have mostly solved the problem.
The end result is that Linux DEs can be horrible to use on many HiDPI laptops, which don't have exact resolutions to make integer scaling feasable.
It is also careful with the resolutions it supports, it is not just any random scale requested. It is always to scale down, but not lose many pixels. For example, with 2560x1600 physical display (rMBP13), you can go to logical 2880x1800 (@1.78 scale) or 3360x2100 (@1.52 scale), but not further.
With Linux (and also Windows), people have weird requests that would not fly in macOS world.
Wayland works the same way.
The quick test is, when I do a screenshot, I get a file with dimensions same as physical display, not logical resolution. On macOS, it is exacly the other way.
Scaling with GPU is more flexible; you can do things per surface instead of per desktop; but slightly more complicated (because you do things per surface instead of per desktop), takes away GPU capacity/memory bandwidth from applications when then might it, and is more power hungry when the GPU could be idle.
What everyone means by "it's like macOS" is that the same "render at ceil(scale) and downscale" general principle is used.
With 2560x1440 display, you won't get fullhd@2x sized desktop (scale 133%) on Apple. That something expected in Linux or Windows, but Apple will get you at most 1680x1050@2x (152%, they're 16:10, so different height) here.
It is compounded by the issue, that Apple traditionally used 72 dpi for @1x scale, while Windows and Linux used 96 dpi. Apple apps look quite good at lower resolutions, while Linux (ok, Gnome) dug itself into a hole and looks good on dpis much higher than 96. For Apple, it is acceptable to run 2880x1900 or 3360x2100 on 2560x1600 display, but when Gnome looks passable on 1600x900@1x, good on 1920x1080@1x and you've got 2560x1440, so you need to display 4K (1920x1080@2x) logical resolution on that... that's more "interesting".
But then hit-testing it with mouse pointer is another level.
Browsers have luxuries that desktop compositor with desktop apps do not have.
The apps would have to cooperate, and that would need rewrite. In many cases, re-architecturing them.
Who is going to do that? Nobody. We need to live with the legacy that we have. How resizing non-compliant applications works (and looks), see the experimental fractional support in Mutter.
The app tells the toolkit to draw a button at 10,10 with a size of 100,20. The toolkit multiplies everything by 1.5 and then draws the button. The app doesn't need to know that this is happening at all. Of course this is not possible with some applications that do weird things, but for the 99% this works, and the 1% can just be resized by the compositor. That's exactly what Windows does.
But Windows is not a garden of roses either, I still see a fair share of blurry dialogs (until recently, even vscode installer/updater).
But it does work. I personally think it looks way worse than just going to 1x (or 2x) and bumping up (or down) the font size.
Unfortunately, it is highlighted by the fact, that all current Linux browsers are X11 and not Wayland clients, so using it would mean you watch the upscaling ugliness on your display every day.
In the gnome world, you are stuck with GTK3 apps if you want partial scaling that looks alright, but there are options for web browsers.
* Epiphany has supported Wayland since the time of the dinosaurs. And I know its not a perfect browser, but it (1) looks native (2) starts up in a second, (3) has libva support support for hardware accelerated video, (4) has a built in adblocker.
As for mainstream browsers:
* Developer builds of Firefox support Wayland straight from Mozilla:
* Most big name distros have some blessed(like fedora) or less blessed (aur/ppa) builds of the latest stable version of Firefox with baked in wayland support.
The Fedora Wayland Firefox package is experimental for a reason; there are bugs, that would be quite embarrassing for a default browser.
It's very serviceable if you are on a fast computer, and hardware accelerated video in a linux web browser is such a treat, but I bet any given release of the big boys has more patches in it than a year's worth of epiphany builds.
As for firefox-wayland, I've seen that fat bug tracker, and it doesn't have webrender or many of the fancier performance stuff working, but it does run well. I've been bouncing between the two browsers for a few months now and there doesn't seem to be any showstopping issues. It's just not as shiny as the real deal firefox.
Hw accelerated videos: some distributions (fedora, suse, arch?) have patched Chromium with VA-API support. On some GPUs, the allow_rgb10_configs raises it's ugly head though. In also works only in native X11, not in Xwayland. Other than that, it is only way to watch youtube during the more intensive compiles :)
Linux on the desktop is death by a thousand cuts. I would argue that it's getting worse and worse, because new technologies are introduced (like scaling, GPU switching like Optimus, touch, good desktop composition, etc) and they are never well implemented. 15 years ago the biggest problem you could have with Linux is having to recompile your kernel to make your sound work or something like that.
The logical solution is to use X for now.
This is more of a client bug than a Mutter bug.
It's very unfortunate Jasper is no longer participating in the GNOME community. I'm hopeful he'll one day return.
These days I'm a professional graphics programmer -- I worked on a few games, fell in love with that, and I'm currently trying to figure out what's next. I don't know if Linux and GNOME are the right communities for me anymore for quite a few reasons.
As always, if people have questions about the work I did, or just want to chat, please feel free to reach out -- my email is in my git commits :)