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