But it's preferable to have applications directly use the Wayland protocol, which is what Firefox is experimenting with. For most applications, this is easy because they use some standard toolkit like GTK or Qt, which will transparently use Wayland without the application caring about it. But Firefox uses its own toolkit, so it's a bit more work.
Regardless of the OS, when the applications want to directly render things they have to communicate with the lower level graphics backend (Wayland, X, DWM, Metal etc) to agree on a memory area and pixel format and some other things. The OS, the direct rendering system and the window management system together manages what application gets the rendering signal, what area, at what display with what metadata (e.g. DPI, or pixel bits) it is drawn.
Since browsers are writing their rendering system and the components from scratch (not everything, they still use some system GUI components or text input / font rendering stuff), they need to communicate with the lower layer directly to request screen areas to render, to get the correct display DPI/scale to draw things at the correct size with well-aligned pixels and to utilize various hardware stuff like hardware video decoders.
However, running programs under XWayland comes with issues such as lack of proper fractional scaling. This means that although not strictly necessary, from a user's point of view it is desirable to have applications move to Wayland.
But it depends on your definition of “application”.
However if you want things toolkits don't provide then you need to talk to the underlying API yourself.
My distro ships both plain Firefox and firefox-wayland. I've been using it for... At least a year. No noticeable difference to normal Firefox.
(Wayland is a set of protocols and the toolkit may not support all the protocols or have sub-par support -- in which case the application can choose to do those bits itself.)
Many applications for Windows, OS X, and Linux interface directly with Win32, Cocoa, or X11/Wayland. For example, the Foot terminal emulator only works with Wayland, because the author has chosen not to implement the X11 protocol.
But there should be performance and rendering quality advantages to speaking Wayland natively.
Core X for instance has zero concept of a frame or buffer swapping, X apps like games generally get that via GL. So your average X GUI application tends to be inherently flickery/tear-ful, since draws just get sent out to the X server and display whenever. XOrg drivers have implemented various hacks to try minimize those effects, but it's all very vendor-specific[0] and never perfect since it's a fundamental limitation of the X protocol. You can at best eliminate literal tearing[1], but nothing prevents displaying a partially refreshed window full of changing widgets, each implemented as X subwindows in the classic X fashion, because nothing in the core protocol says "Ok, this top-level window update is finished, present it (and its descendants)!".
That's not even getting into the issues of high dpi and fractional scaling...
[0] https://manpages.debian.org/bookworm/xserver-xorg-video-inte...
As far as design goes, Wayland is absolutely awfully verbose for no good reason.
Not to mention that so many fundamental things are optional extensions that there are five completely incompatible extensions for each possible API that Wayland leaves out. Like screenshotting.
You see this if you look at e.g. XRender. XRender was a big improvement for X, by providing a set of rendering primitives. Yet at the same time they repeated mistake after mistake from the core protocol. E.g. the flexibility in visuals that mattered when we did have monochrome, 8-bit palettes, 15-bit direct color, 16-bit direct color and 24-bit truecolor graphics output in the same computer lab no longer matters when you can assume that every server can provide RGB24 and RGBA32 visuals, not least because XRender demands this so if a server wants to support XRender, it must support RGB24 and RGBA32 whether or not that's a natural fit for the backend or not.
Yet it still makes you iterate through a list of every weird format known to man (and some that feel like they must be alien) even when you want to look up one of the 5 standard formats Xrender dictates that every server must support. Xrender could have just made the relevant request return 5 ints.
It's not hard to deal with the current solution, but it's pointless and it makes the server unnecessarily complicated to still support all of those extra visuals that almost nobody will be using, and nobody needs to use.
If that was all, it wouldn't be so bad, but this is typical for XRender, and this is why X became unmanageable: They both left the core protocol intact, but each extension they added was just as bloated as the core was.
Nothing would stop you from fixing this by bumping a version number and start deprecating requests and introducing replacements. But that only works if you can get buy-in into changes that actually simplifies things, and the XRender extension is a good indication that this was the real problem for X: You'd get buy-in for changes, but changes that only ever added complexity.
This was particularly idiotic because Xorg came to pretty much control this space: Almost everyone used the same X server and almost everyone used the same Xlib. They could have bumped the protocol version and started deprecating old functionality whenever they wanted while optionally papering it over in the client lib to give people time to update their clients.
So Wayland became a way of escaping that and starting over. And it could have been great if they weren't so afraid of repeating the same complexity mistakes that they repeated the same complexity mistake by proxy by forcing even basic functionality into extensions where there was no ability to reign it in. The Wayland design reliance on extensions made an explosion in complexity virtually guaranteed.
I wish they'd have forked Xorg instead, and had the guts to gut it and clean it up: Bump the major version to 12. Set out an aggressive deprecation schedule and ensure a sufficient set of apps would keep working with various calls and visuals yanked out. Optionally add a shim to xlib/xcb to temporarily handle some of the deprecated functionality client side (e.g. most old rendering calls and bitmap font handling could easily be transitioned this way). Then you'd have a base to iterate from where you could iterate step by step from a working starting point. Then maybe we'd all be on something new and working instead of having this ongoing schism that won't be resolved anytime soon.
That's exactly the reason why everything is an extension is Wayland: so the client is forced to enumerate, what features are available and adjust its behavior when something is not. It is exactly this, that allows Wayland to drop features, once they became obsolete. It is the lesson from not being able to drop core X11 primitives.
Of course they can. Dropping it from new versions won't wipe old servers off the planet, and as we can see from the existence of Wayland, the OSS world is very much prepared ditch far more backwards compatibility than just breaking an occasional obsolete client.
If anything, it's a far easier transition because shimming some Xlib calls is far easier than migrating applications to a whole different display model.
> That's exactly the reason why everything is an extension is Wayland: so the client is forced to enumerate, what features are available and adjust its behavior when something is not. It is exactly this, that allows Wayland to drop features, once they became obsolete. It is the lesson from not being able to drop core X11 primitives.
That doesn't work that way once something becomes reasonably ubiquitous. Experience from X is that people will expect a given extension to be there (heck, most of my own X software will categorically not work on an X server without XRender, so if that extension is ever dropped from X, my software will stop working and need to be updated - that's a tradeoff I'm perfectly fine with), not have older alternatives that make sense, and obviously not be able to predict future alternatives that do not yet exist.
In other words: You'll still need to either support those APIs, or deprecate them and update the clients. Doesn't matter if they're part of the core or extensions.
"Render as quickly as possible (even if imperfect)" is also a viable strategy. Some people seem to really hate it, but I've never even noticed it, much less been bothered by it. I certainly prefer the reduced latency. I'm probably not that special. It very much seems like a trade-off thing, rather than "this is the one true correct way"-thing.
Of course, it would be better if Xorg would support both, but that also applies to Wayland.
With XOrg, especially in the pre-compositing days, you could choose whatever WM you want and it wouldn't have any impact on the rendering performance of X clients. Once the Composite extension was added and everyone started running composited X desktops, that started to change, and the increased latency already started appearing - in an arguably worse architecture than Wayland because there were often three processes involved with lots of IPC/context switches per draw: X-Client->X-Server->X-Compositor->X-Server->CRTC. At least in Wayland it's more like Wayland-Client->Wayland-Compositor->CRTC.
If you're unhappy with the rendering latency of your Wayland sessions, it may be worth trying alternative compositors... they likely vary significantly. The Valve/Steam folks have made a minimal one specifically optimized for games/low-latency [0]. I doubt the SteamDeck would be seeing as much success as it is if Wayland were so problematic in this department.
I don't use a compositing WM. I would have to check how the performance compares to a compositing WM.
It's just one more thing that's worse-out-of-the-box with Wayland that I need to find a solution for, while at the same time solving exactly zero issues for me.
The idea is that GTK+ and Qt can (and do) add support for Wayland and it's trivial for applications to support Wayland, often without even recompiling.
Applications built for X can still run on Wayland via Xwayland. But Xwayland is a bodge to allow legacy applications to continue running, an interim solution while toolkits, libraries, and applications are converted to use Wayland directly. To paraphrase the hit song:
Once we have enough Wayland software
At our call, hackers, at our call,
We'll throw out those dirty X code paths,
Ever more, hackers, ever more.See SDL_DYNAMIC_API: https://www.reddit.com/r/linux_gaming/comments/1upn39/sdl2_a...
Any information most welcome.
The protocol is defined in the libwayland library. Most apps don't use libwayland directly, but their widget toolkit like GTK or Qt does it for them.
instead it's all shared memory buffers