Announcement

Collapse
No announcement yet.

Does The Display Server Matter? The Latest Mir vs. Wayland Argument

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by Massa View Post
    Why are they spending hundreds of thousands of dollars (possibly more) on Mir if "it doesn't matter" to the end user?
    It matters to them because they are providing what does matter to the end user, they have to make it work well, and they think Mir is their best approach for doing that.

    Comment


    • #22
      Originally posted by Massa View Post
      Why are they spending hundreds of thousands of dollars (possibly more) on Mir if "it doesn't matter" to the end user? They don't have support from the hardware vendors, the Mesa community, GNOME or KDE... who wants this? Why?
      Robert was already asked this question. His response was, approximately, I don't pay the bills, so don't ask me.
      That bought him some respect in my eyes. I think he is well aware that Mir doesn't make any technical sense.
      OTOH, he was the one who made the post about the servers not mattering, so... perhaps it's all awash?

      Comment


      • #23
        Originally posted by emblemparade View Post
        On that note, it would be nice if Canonical folk would stop making these degrading comments.
        So Ubuntu developers shouldn't be allowed to make comments about technical matters on their personal blogs?

        Comment


        • #24
          As much as I usually don't agree with them (and in all honesty I really do not like the company), Canonical is correct in one thing. Applications (outside of a limited set of corner cases) should be agnostic to the underlying display server (this should not be taken to mean that they should support all display servers but that the application shouldn't need to know those details), if they aren't then that's either a problem with the design of the application or a toolkit bug (What Martin highlighted were really nasty hacks around toolkit bugs). The entire point of Qt is that you write code once in a clean platform independent fashion and it'll run anywhere because all of the platform details have been abstracted away into a QPA plugin, if it's not working that way then that's a problem with Qt.

          The OSD and system notification example that was highlighted by Aaron is mildly disingenous because if a DBUS API doesn't exist for a generalized problem like that where there should be a DBUS API, the solution isn't really to hack around the lack thereof but to design and create an appropriate DBUS API to handle it, and get it accepted and used. Unlike closed source software we don't need to hack around deficiencies in the underlying platform and make an ugly mess, we can fix the underlying platform. Yes what should and what does happen are two completely different things, but that doesn't shift the responsibility away from doing what's right as opposed to creating an ugly hack.

          Now there are certainly a class of programs that should be aware of the underlying platform, but these aren't applications, they're things like compositors where the entire point is that they speak that protocol

          Comment


          • #25
            Originally posted by Hibiki Kanzaki View Post
            It matters to them because they are providing what does matter to the end user, they have to make it work well, and they think Mir is their best approach for doing that.
            well after testing ubuntu unity 8 snapshot + ubuntu on my nexus and wayland in gnome 3.12, i can say for sure Mir is at least a year(if developed full steam ahead) from wayland state today. So far Mir is less performant, is not very stable(with intel it crashes a lot and with the nexus 4 too) and they havent reached perfect frames synchronization(some animation have very wierd behaviors specially under load). On the other side Wayland is impressive specially with radeonsi/r600g and pretty rock solid so far(mutter was a bit unstable at the begining of the 3.11 cycle) but it misses few key points tho like full gdm session and accelerated Xwayland without glamorwl-git or xwayland flash crash on firefox(chrome pepper seems to work just fine in v.33 -- havent tested aura-wayland tree).

            i tested MPV on wayland too and is perfect absolutely perfect even on 40GB bluray high bitrate scenes(big kudos for MPV devs) btw Qt5 on wayland is quite a beast too already for normal apps, especially the canvas intensive type, with wayland is almost free and QML animation are butter smooth(haven't tested KF5 yet tho).

            i havent tested touch/tablet input since i don't use them and epiphany is quite impresive rendering on wayland even tho i don't love it as a browser interface i have to admit is even more fluid than safari on OS X in page render, scrolling and fluidity.

            another thing i did is use the gallium hud and process memory tracking and i have to admit run as wayland client is almost RAM free(in fact you shave around 100M of ram usage from X backend just like that) and the hud barely do anything to render a full wayland desktop like gnome 3.12(ofc all this test are not representative of anything but my own system and are not intended to be used as proof of anything beyond inspire you to do your own test on your own system or pick michael curiosity )

            Btw color correction is quite good already(for my eyes) maybe an graphic expert could compare it to OS X for fun

            in conclusion i dont mean to demerit Mir but to point is needed more time to reach wayland current state since they still are quite behind

            Comment


            • #26
              Whom is Canonical trying to fool? The apps won't need to change, but the toolkits they use will need to support two display servers instead of one. Canonical wants us to believe that 2 == 1

              Comment


              • #27
                Originally posted by liam View Post
                Robert was already asked this question. His response was, approximately, I don't pay the bills, so don't ask me.
                That bought him some respect in my eyes. I think he is well aware that Mir doesn't make any technical sense.
                Well that is one way to interpret his posts. What he said was:

                Originally posted by Robert Ancell
                Because they think it will be faster to develop Unity like that? Because they think it will be better quality? ... you may be shocked to know I don't pay the bills at Canonical so I'm almost certainly not the right person to ask that.
                So another interpretation would be that he believes that it is because "they think it will be faster to develop Unity like that.. they think it will be better quality".

                That's the wonderful thing about interpretations; everyone gets to choose their own based on pre-existing biases

                Comment


                • #28
                  Originally posted by Luke_Wolf View Post
                  As much as I usually don't agree with them (and in all honesty I really do not like the company), Canonical is correct in one thing. Applications (outside of a limited set of corner cases) should be agnostic to the underlying display server (this should not be taken to mean that they should support all display servers but that the application shouldn't need to know those details), if they aren't then that's either a problem with the design of the application or a toolkit bug (What Martin highlighted were really nasty hacks around toolkit bugs). The entire point of Qt is that you write code once in a clean platform independent fashion and it'll run anywhere because all of the platform details have been abstracted away into a QPA plugin, if it's not working that way then that's a problem with Qt.

                  The OSD and system notification example that was highlighted by Aaron is mildly disingenous because if a DBUS API doesn't exist for a generalized problem like that where there should be a DBUS API, the solution isn't really to hack around the lack thereof but to design and create an appropriate DBUS API to handle it, and get it accepted and used. Unlike closed source software we don't need to hack around deficiencies in the underlying platform and make an ugly mess, we can fix the underlying platform. Yes what should and what does happen are two completely different things, but that doesn't shift the responsibility away from doing what's right as opposed to creating an ugly hack.

                  Now there are certainly a class of programs that should be aware of the underlying platform, but these aren't applications, they're things like compositors where the entire point is that they speak that protocol
                  well this is true for most of your normal consumer's application, i mean a social network apps for example don't have to care about anything than Qt5 already don't offer in a platform independant way or text editor or regular office suites,etc.

                  the problem most likely will present itself on games and enterprise applications than regardless the OS/toolkit always will go down as closer to the hardware as they can to squeeze performance at any cost(sdl2 just tackle part of the problem), for example an professional canvas application (Gis/CAD/Design/Military,etc) will probably go all the way to use EGL/Wayland file descriptors with a custom render/composite stages processes instead of depend on scenegraph simply because of efficiency and specialization, ofc you have embed/industrial and other scenarious that need to get closer to the hardware for certain processes too.

                  now i agree with you that a mom or an lawyer or any regular home user don't care about this but the big money funding this project is precisely in that 5%-20% of specialized users and bussiness and the pockets you are touching by releasing for fun something like Mir is theirs(btw many advanced wayland features are coming from this scenarious from the big pocket boys), so the problem was never a opensource project saying "i don't have enough resources to support both" but "now i have to waste money on another platform when with wayland almost all our need were discussed, implemented and backed with proper support of khronos and Xorg foundation."

                  so if Mir see the light in 2016 like canonical said, i believe it will compete more against android than against wayland in that sense(it wont surprise me if ubuntu keep mir for mobile and support wayland for desktop), since all those big shots(same bigshots that love send money to RedHat) will stay with wayland for bussiness/support/warranty reasons(after all home and mobile is not their target bussiness and canonical is too dangerous for a long relation investment in the enterprise sector)

                  Comment


                  • #29
                    Originally posted by chrisb View Post
                    Well that is one way to interpret his posts. What he said was:



                    So another interpretation would be that he believes that it is because "they think it will be faster to develop Unity like that.. they think it will be better quality".

                    That's the wonderful thing about interpretations; everyone gets to choose their own based on pre-existing biases
                    That's a fair point about biases.
                    The two possibilities he mentioned are, you'll notice, ones than would've been reasonable for him to openly adopt IF he believed them. However, that's not how he chose to phrase it.
                    However, as you say, we all have biases and thus interpret things accordingly.
                    One more thing, just because we have biases doesn't mean we can't do something about them. It requires the regular practice of metacognition. That's a fancy term, but for non English speakers it simply refers to the process of critically thinking about your own thinking (or, more appropriately, your reasoning). At a minimum this can be done by finding an alternative explanation, or in this case, interpretation, of something, and then comparing the two by examining their assumptions.
                    In this case, when looking at the two given interpretations, why he wouldn't just say that he thinks the Mir approach is better (in the ways he described as possibilities) rather than simply suggesting them as possibilities (while omitting the advantage of canonical having a cla'd server as a possibility) is because he doesn't believe there is an actual technical advantage. Of course, of in the past, or future, he says otherwise I'll revise my assessment.

                    Comment


                    • #30
                      Originally posted by HeavensRevenge View Post
                      In Mir every window is it's own completely separate compositor making it an orchestration of compositors to create a final display output
                      wow, if this is true, they are batshit insane

                      isn't the point of widget toolkits and desktop envrionments to get consistency across applications? how will you get that if you have 4 applications, each compiled against different version of the same compositor? let alone ones compiled against QT and ones against GTK?

                      they have lost and the fight haven't even started

                      Comment

                      Working...
                      X