elementary-dev-community team mailing list archive

[Cassidy James <cassidy@xxxxxxxxxxxxxxxx>]

Hey Sergey,

You're right in the notion of Ubuntu's community manager and the
founder/leader of elementary not being the best people to discuss Mir on a
strictly technical level. That alone tells me to expect the discussion to
be more high-level and of a political/business nature.

We already expect to ask the, "Why would we use this instead of Wayland?"
question. That's a given. If you have any other specific questions that we
could ask, let us know.

Regards,
Cassidy James
On Jul 8, 2013 3:54 AM, "Sergey "Shnatsel" Davidoff" <
sergey@xxxxxxxxxxxxxxxx> wrote:

> 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
>
> --
> Mailing list: https://launchpad.net/~elementary-dev-community
> Post to     : elementary-dev-community@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~elementary-dev-community
> More help   : https://help.launchpad.net/ListHelp
>
>