elementary-dev-community team mailing list archive

[Daniel Foré <daniel@xxxxxxxxxxxxxxxx>]

Sergey,

Like Cassidy said, I'm sure this will be a much more political discussion than a technical one. Obviously I'm not going into the call with the intention to personally make a decision about Mir vs Wayland. 

This is an opportunity to speak to someone at Canonical directly and get some insight into not only why we might want to use Mir, but why they wanted to use Mir. Don't forget that Canonical was also in the Wayland camp for quite a while.

And while I don't expect Jono to have vast technical knowledge on the subject, I've met him in person and he's a competent fellow. It's part of his job description to have a high level overview of just about everything in Ubuntu (including the underlying tech). So I imagine he should be able to answer any technical questions we might have.

That said, I'm not exactly a dunce myself either ;)

Best Regards,
Daniel Foré

El jul 8, 2013, a las 1:54 a.m., "Sergey \"Shnatsel\" Davidoff" <sergey@xxxxxxxxxxxxxxxx> escribió:

>> 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, for example.
> 
> We have some preliminary benchmarks 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 "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