Blender’s Wayland support is not great because they’re doing stuff from scratch. They’re not using an existing toolkit like GTK, Qt, Electron, or even something like SDL to get Wayland support.

But if you’re using an existing toolkit things are much easier and support is automatically there, you just need to do testing to ensure everything works.

The common biggest things that still use Xwayland are Chromium based apps and programs running under wine/proton. Chromium has an experimental Wayland mode that works well enough, but definitely has some bugs, especially around windowing. Wine Wayland is in the works.

You’re asking the Linux community to agree on something

for better and worse, XWayland works perhaps too well

Because it doesn’t matter for most apps. XWayland works fine.

Even Blender says if it fails to use Wayland it will use X11.

What are you trying to say? Of course it does. Pretty much every Linux app still supports X11, because a lot of people are still using X11. Only exception I’m aware of is Waydroid.

Because Wayland is fundamentally very different from the older X protocol, and many programs don’t even directly do X. They leverage libraries that do it for them. Those libraries are a huge part of the lag. Once GTK and Qt and the like start having a stable Wayland interface, you’ll see a huge influx of support.

A big part of the slowness is why Wayland is a thing to begin with. X hid a lot of the display hardware from apps. Things like accessing 3d hardware had to be done with specialized display clients. This was because X is natively a remote display tool. You can use X to have your program show its display somewhere else. Wayland won’t do that because that’s not the point. Applications that care will have goals for change. Applications don’t care will support it once someone else does it for them.

Right now, the only things that would benefit from Wayland are games and apps that make heavy use of certain types of hardware. Half of those don’t care about linux, while the other half is OK with X and xwayland.

good is the enemy of excellent. X11 works for most users (almost all the users?) well. You can see that with the adoptions of other standards like the C++ standards and IPV6 which can feel like forever.

Another thing I think one of the X11 maintainers mentioned iirc is that they have been fairly gentle with deprecation. some commercial company could have deprecated X11 and left you with a wayland session that is inferior in some ways.

Also XWayland has many limitations as X11 does.

If an app has only ever supported X11, then it probably doesn’t care about those limitations (the apps that do care probably already have a Wayland version). And if an app doesn’t care about the extra stuff Wayland has to offer, then there’s not really a reason to add the extra support burden of Wayland. As long as they work fine in XWayland, I think a lot of apps won’t switch over until X11 support starts dropping from their toolkit, and they’ll just go straight to Wayland-only.

Because Wayland is STILL lacking a lot of things that people need.

As someone who tries to look under the hood for a lot of the open source software I run, one thing that I have noticed is that there are a lot of cases where the general sentiment seems to be port to what. Wayland still doesn’t support a number of things that some applications require. A lot of developers that I have interacted with would rather have the app run through XWayland rather than have a wayland version of the app with less features or certain features grayed out.

In the case of one project in paticular, that being the Sunshine game streaming project. I have personally witnessed. Them implementing a solution for wlroots based compositor. Having that solution eventually break as wlroots based projects deprecate the protocol they were using in favor of a new one and now that protocol is looking like it too is old news and is going to be deprecated in favor of a newer and better protocol. What I am getting at here is that protocols not existing isn’t the only problem, but things are still very much in development. Even applications that implemented wayland support are being put in positions where they need yet another rewrite because things are far from finalized and still moving pretty fast.

Wayland for better or for worse is still in development, it’s actively changing and a lot of developers can’t (or don’t wanna bother) keeping up…

So software like CAD is funny. Under the surface, 3d CAD like FreeCAD or Blender is taking vertices and placing them in a Cartesian space (X/Y/Z - planes). Then it is building objects in that space by calculating the mathematical relationships in serial. So each feature you add involves adding math problems to a tree. Each feature on the tree is linearly built and relies on the previously calculated math.

Editing any changes up tree is a massive issue called the topological naming problem. All CAD has this issue and all fixes are hacks and patches that are incomplete solutions, (it has to do with π and rounding floating point at every stage of the math).

Now, this is only the beginning. Assemblies are made of parts that each have their own Cartesian coordinate planes. Often, individual parts have features that are referencing other parts in a live relationship where a change in part A also changes part B.

Now imagine modeling a whole car, a game world, a movie set, or a skyscraper. The assemblies get quite large depending on what you’re working on. Just an entire 3d printer modeled in FreeCAD was more than my last computer could handle.

Most advanced CAD needs to get to the level of hardware integration where generalizations made for something like Wayland simply are not sufficient. Like your default CPU scheduler, (CFS on Linux) is setup to maximize throughput at all costs. For CAD, this is not optimal. The process niceness may be enough in most cases, but there may be times when true CPU set isolation is needed to prevent anything interrupting the math as it renders. How this is split and managed with a GPU may be important too.

I barely know enough to say this much. When I was pushing my last computer too far with FreeCAD, optimising the CPU scheduler stopped a crashing problem and extended my use slightly, but was not worth much. I really needed a better computer. However looking into the issue deeply was interesting. It revealed how CAD is a solid outlier workflow that is extremely demanding and very different from the rest of the computer where user experience is the focus.

In my opinion, that’s because X11 lacks proper abstract for many things like screenshot, screencast, color managerment and etc, so the applications have to use many X11 implementation details to implement these features. It leads to high-coupling code with X11 so move their code to wayland and ensuring it works correctly and is consistent with the old behavior is difficult.

It is still young and underdeveloped.

It is advertised to be simpler, but I don’t understand any of this words thrown in this thread. And I don’t care. Pulseaudio and pipewire is still making me troubles, even thou alsa worked without issues for me.

Point it, make it clear and stable and we will come. Until than we will use the beast we know. It os mich easier when there are no options, but Wayland is fighting something that exists and it takes time and effort.

Another problem is they pushed it to early and people got burned. Until I start seeing “I switched to Wayland in one command and everything works” I (as a user) will not touch it (unles my distro decides to drop X).

Because it’s so complicated that given a page (page and a half) to answer the simple question, “Why does Wayland support still give you more problems than solutions?” We had to describe it like the summary of a PHD theses in client server architecture?

Come on with that load of hot trash 😭