XWayland 2D Performance Appears Better Than XMir

[r_a_trip]

What about having WaylandMir and MirWayland, like we have XWayland and XMir?

Oh God no. If we are going to stuff up our modern display server with hacky abstraction layer upon hacky abstraction layer, just so we can sub-optimally run the apps that now run acceptably everywhere because of X.org, then please, please, please, stop building replacement display servers. We're better off with X.org alone.

And the "What about having WaylandMir and MirWayland" is exactly the illustration of why Mir is such a stupid idea in the first place, it creates tension and technical problems where there need be none. If Canonical had poured the same amount of money and effort into Wayland, they would be running Ubuntu Touch upon Wayland already and they would be assured of being able to run all FOSS apps that currently run on X.org.

Now Canonical is taking a Microsoftian gamble that more developers will target Mir than Wayland and that they will come up on top because they have the larger application catalog and users will be enticed to solely use Ubuntu. I think that will prove to be a pipe dream, but hey, it's a ballsy move and it'll make a great story for the youngsters if they want to know what came before Wayland.

[robclark]

The claims of the article that this is an apples2apples comparison of what the Xmir configuration is would appear to be inaccurate. The test results linked to in this article seem to indicate that XWayland (Xorg+Wayland) are actually better in 5 out of 9 cases vs standalone Xorg. It does not seem reasonable that Xorg would be slower than Xorg+"anything".

Xmir is Xorg+mir as a system compositor. I am tempted to believe as one other poster has pointed out that in these instance Xorg is not involved, and rather what is being measured is a native Wayland rendering.

well, in the same way that different window managers can have an effect on performance, compared to Xorg + $some_random_window_manager, Xorg + weston could well be faster. Weston has a gles2 compositor backend which is actually quite efficient, and in a lot of non-fullscreen cases can do better than any gl/gles compositing window manager on vanilla Xorg. So better results than plain Xorg don't really surprise me too much.

[Guest]

Except there appear to be 0 people willing to use a GPL3 display server.

BSDs won't.

Doesn't matter. They didn't ever contributed a thing to Linux desktop and I don't care about spongers.

Smartphone manufacturers won't.
Other embedded device manufacturers won't.
KDE won't.

Not sure about GNOME3 or XFCE, but i bet they aren't crazy about it either.

Which means Canonical does control Mir, because they're the only ones who can re-release it in a license that people will use.

You don't know what people will use. I'm not defending MIR here, but I think it's too early to make such judgments.

[alexThunder]

Now Canonical is taking a Microsoftian gamble that more developers will target Mir than Wayland and that they will come up on top because they have the larger application catalog and users will be enticed to solely use Ubuntu.

It wasn't Canonical, who just excluded the possibility of MirWayland/WaylandMir, it was you. To call them "Microsoftian", because you don't want to have that layer, seems odd to me.

I agree that it would (probably) have been the better technical choice, to stick with Wayland and just work on it, but I guess, Mir was more of a political decision. However, now Mir's there (more or less) and it's unlikely that Canonical will change it's mind - it's also unlikely that Wayland will be dropped, so MirWayland/WaylandMir seems the only way to prevent Ubuntu-exclusives. Furthermore, I wouldn't be too worried about the overhead, since, according to XMir and XWayland, it doesn't seem to be that big (count in the early-days-factor of Mir).

[Guest]

That myth is only about the details of taking a "serial" task and trying to do it quicker. Development of larger systems is often a highly parallel task. That is, you can have someone work on getting 3D accel in XWayland while someone different works on input method management and so on. You can do a decent number of things at once in some software development if only you can afford to pay enough people (FOSS does not, of course, and save for a few exceptional cases like the Linux kernel where there's a large amount of commercial interest, FOSS projects are usually severely understaffed - people with the requisite skill generally want to get paid highly for it and then aren't interested in doing hobby work in their off time when they have spouses, children, and social lives to look after besides their 40+ hour work-weeks).

Many of the FLOSS projects are much better than their proprietary counterparts. Many of the FLOSS developers are well payed developers. Many of the FLOSS "hobby" projects are much better than, so called professional ones. That's a nature of FLOSS.

[Pajn]

No, Wayland is going to be better because it's developed by people who know what they're doing, instead of simply copying stuff from people who know what they're doing...

Sorry but that doesn't stick.
If I have fast code in one folder and copies it to a different folder the copy won't be slower.

The facts is:
Mir is missing some important pieces for performance right now.
XMir emulated a full desktop environment while XWayland only emulated the benchmarked app.
The test where run on different hardware.

A. These test arent comparable at all as they where run in very different way measuring different stuff.
B It's stupid to measure Mir perfomance right now except for seeing how different changes affect the performance.

[mrugiero]

What about having WaylandMir and MirWayland, like we have XWayland and XMir?

For Mir on Wayland you'd need a somewhat stable API. Else, you'll spend all of your devs on playing catch up. And Canonical didn't make that compromise, and in fact, they said (it's mentioned on one of the developer's blog) they "don't intend reimplementations, and will make no effort to not break the API". I quote it almost textual (I already closed the tab, an I'm not positive I recalled it correctly, but I copied the meaning as stated, not "we will break because we hate you and we are evil!!!1!!ONE" nor "we are so nice we assure you we will not break, so you can reimplement all you want", but they do not intend to be helpful in that regard) to avoid misunderstandings of the kind I put between braces.

Also, should be noted that in the case Canonical maintains this Mir over Wayland for the sake of contributing, then they'd probably be better of implementing Mir as a Wayland compositor and that's it. Which would have been probably the sane thing to do from day zero.

In the same way, for Wayland on Mir you'd need this stable API, but Wayland on Mir is more likely to be done by Canonical than by the rest of the community, and since Canonical (and it's community) are the ones who can break the API, they can as well spread the changes to Wayland on Mir on the same move.

*However*, as long as Mir is Unity only, one can hope whoever codes for Mir will code for Unity, and will do so by targeting Qt (what one should hope, since Mir's API will not be stable, is that they wouldn't target Unity directly, but Qt. Mir's API being unstable kind of warrants nobody will directly target it). If it's done this way, every app coded for Mir will work out of the box on Wayland, as long as you have Qt installed.

well, in the same way that different window managers can have an effect on performance, compared to Xorg + $some_random_window_manager, Xorg + weston could well be faster. Weston has a gles2 compositor backend which is actually quite efficient, and in a lot of non-fullscreen cases can do better than any gl/gles compositing window manager on vanilla Xorg. So better results than plain Xorg don't really surprise me too much.

I kind of forgot this part (the window management) when I listed basic things that could be ignored when running single apps on XWayland/XMir.

[mrugiero]

Sorry but that doesn't stick.
If I have fast code in one folder and copies it to a different folder the copy won't be slower.

The facts is:
Mir is missing some important pieces for performance right now.
XMir emulated a full desktop environment while XWayland only emulated the benchmarked app.
The test where run on different hardware.

A. These test arent comparable at all as they where run in very different way measuring different stuff.
B It's stupid to measure Mir perfomance right now except for seeing how different changes affect the performance.

Better and faster are two different things.
Sometimes faster comes with crashes, and stable implies slower. How would you define 'better' there? The faster, or the more reliable? Depends on your priorities and the specific use case. It's not the same if a video keeps crashing (it really breaks the atmosphere a movie might be trying to set) but the time it works can put 600FPS on screen, than a web browser which is stable as hell but takes a minute to load each message on an IRC window. Both cases are shitty as hell, even when in one aspect are DA BEST.

On the other hand, what is compared is what will be relevant for the user. The comparison itself is bad for said reasons, but that doesn't change a bit what the end user will perceive. XMir will be running the desktops in 13.10 and 14.04, which is a LTS. IMO, this is nonsense. On Wayland, there's no plans of releasing a distro with it until there's a working native DE on it, and XWayland is, in consequence, meant only for unsupported *single* applications, and this is what Wayland users will see.

I agree on the point that it's stupid to compare performance right now, though.

[dee.]

Sorry but that doesn't stick.
If I have fast code in one folder and copies it to a different folder the copy won't be slower.

The facts is:
Mir is missing some important pieces for performance right now.
XMir emulated a full desktop environment while XWayland only emulated the benchmarked app.
The test where run on different hardware.

A. These test arent comparable at all as they where run in very different way measuring different stuff.
B It's stupid to measure Mir perfomance right now except for seeing how different changes affect the performance.

What mrugiero said, and also: you can't just complain that "it's unfair to Mir because it's still missing pieces", because... how does the same not also apply to Wayland? Wayland is also still missing some pieces (when it comes to DE and distro implementation, mostly).

But anyway, I'm confident that in due time, Wayland will wipe the floor with Mir.

[dee.]

For the last time, this is not true. Fedora plans to have an optional wayland gnome session by fedora 20, and wayland by default for fedora 21. The plan isn't concrete and subject to change obviously, but saying "no distros plan do adopt wayland is totally false. Most distros will wait a bit longer, but once gnome and KDE fully support wayland (and there is good progress happening here for both desktops) distros will begin to adopt it (right now there isn't any point for distros adopting wayland, or mir for that matter, if gnome and kde don't fully support it yet...).

...and? Gnome is a DE. What was said was "there's no plans of releasing a distro with it until there's a working native DE on it" - and Fedora most likely won't release a Wayland-based release until they have a DE (ie. Gnome or KDE) that works natively on it.

It should also be noted that ubuntu's first "mir releases" are just xmir running unity 7, canonical certainly won't be releasing desktop ubuntu with a "mir native desktop" any time soon either. I'm so sick of this ridiculous FUD that wayland will never be ready and that no one plans to adopt it. it is NOT TRUE.

Right, but that's only said by the ubuntu fanboys who swallow everything Shuttleworth ejaculates...