elementary-dev-community team mailing list archive

["Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx>]

>
> I was recently contacted by Jono Bacon from Canonical. We'll be on a call
> Tuesday to talk about the pros and cons of Mir and whether or not it fits
> in with elementary.
>
> If you have any questions or concerns that you'd like me to bring up with
> Jono, please let me know.
>
> I'll be sure to take good notes on his responses so that we can make an
> informed decision about how to move forward.


I really appreciate the move, but I'd expect discussions about low-level
components like display servers which users don't even notice to take place
between people actually competent with the tech, not a community manager on
one side and a UX designer on the other. Perhaps a conference call or a G+
hangout is more appropriate, with more people on our side at least.

That said, here's what I gather regarding Mir so far.

The first thing to understand about Mir in 13.10 and 14.04 is that it
functions as a *system* compositor. So you still have all your traditional
X sessions just like in Precise, but on top of them you have *yet
another*compositor (Mir) which provides smooth transitions between
sessions
(instead of ugly VT switching) and lets us utilize LightDM as lock screen.

Using Mir as a system compositor and using it as the only display server
are completely different things. For 14.04 we're talking about using it as
a system compositor only. The primary concerns with using it as a system
compositor are performance and stability - this is why Kubuntu
rejected Mir<http://blogs.kde.org/2013/06/26/kubuntu-wont-be-switching-mir-or-xmir>,
for example.

We have some preliminary<http://www.phoronix.com/scan.php?page=article&item=ubuntu_xmir_benchmark&num=1>
benchmarks<http://www.phoronix.com/scan.php?page=article&item=ubuntu_xmir_2d&num=1>of
Mir as a system compositor, but they're not really meaningful because
vertical synchronization was disabled and they're just measuring how much
raw GPU power another compositing layer gobbles up. But raw GPU power is
just about the least of our concerns. Compositor synchronization is a much
trickier problem - read some articles on the topic at
http://blog.fishsoup.net/ to get an idea of how compositors work and just
how tricky synchronization is.

Synchronizing the application with just one compositor is problematic
enough, but it's mostly solved thanks to GNOME's heavy and continuous
investment it it. But synchronizing the whole thing with yet another
compositor on top of it that has completely different protocols and inner
workings - that's not something I believe to be possible at all. And due to
poor synchronization we'll get a bouquet of issues like jitter (disgusting
video playback, yay!) and high latency.

Don't get me wrong, having a system compositor is actually a good idea,
given a suitable implementation. It's very perspective in the Wayland world
because the Wayland protocol is designed to allow nesting compositors - you
can stack as many Wayland compositors as you want, and as long as a
compositor does not perform any operations with the frame it receives from
an underlying compositor, it can pass the frame to the next compositor or
display it without introducing any additional overhead. So you effectively
have just one compositor in the process and the second one kicks in only to
draw transitions between sessions.

This still holds if you throw some X applications on XWayland into the mix,
because they're run in tiny rootless per-app X servers without their own
compositors. This is not the case for what Canonical is up to, though -
right now they still have a compositor in X and a Mir compositor on top of
that, so you inevitably pass every frame through two completely different
compositors that cannot even talk to each other, so there's like no
synchronization between them whatsoever?

With all due respect to Jono, I'm not sure he's sufficiently qualified to
understand the details of inner workings of compositors and explain them to
us. (Hell, I'm not even sure if I'm sufficiently qualified to understand
the explanations!)

Regarding ditching X for Mir, I believe this is out of question. We already
have Wayland support for Gala for free and porting it to Mir is not simply
a waste of effort - it's a continuous waste of effort because Mir protocol
is not stable or frozen, unlike Wayland protocol. And I doubt we have the
resources to do so in the first place anyway.

Also, I've never seen an explanation of why Mir is superior to Wayland.
There's a wiki page<https://wiki.ubuntu.com/Mir/Spec#Why_Not_Wayland_.2BAC8_Weston.3F>"explaining"
that but the only real argument in there was erroneous and got
removed over time. I'm really, really curious what Jono has to say on the
topic.

-- 
Sergey "Shnatsel" Davidoff
OS architect @ elementary