Announcement

Collapse
No announcement yet.

The Wayland Situation: Facts About X vs. Wayland

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

  • Originally posted by nzjrs View Post
    Thus proving daniels (and the other wayland/x11 developers point). They actually know the details of the domain in which they are hacking.

    You are arguing from ignorance. How about we trust their experience and technical acumen a little?
    Proving what? It proves my point that there exists at least one toolkit that does it properly.

    Comment


    • Qt 4 draws into a bitmap first, so for anything Qt text remoting would indeed not work.

      Comment


      • Pango depends on the backend: cairo and FT go to images, Xft backend text.

        Okay, I was wrong here, the popular toolkits don't draw text in a way that could easily pass it forwards.

        However, modifying them to do so is significantly less work than inventing a protocol for each toolkit.

        Comment


        • Originally posted by curaga View Post
          Pango depends on the backend: cairo and FT go to images, Xft backend text.

          Okay, I was wrong here, the popular toolkits don't draw text in a way that could easily pass it forwards.

          However, modifying them to do so is significantly less work than inventing a protocol for each toolkit.
          Then do not invent a protocol for each, but a shared drawing standard. The thing is, when you make a monolithic specification, you'll then have to drag behind you the legacy functionality for things unrelated to your actual concern, and they get in the way. If toolkit people feel they need a standard for drawing so they can draw over the net and such, they could make a platform independent drawing protocol, which would be able to run over Wayland and get dropped later if needed without having Wayland needing to carry their mistakes for backwards compatibility. Again, Wayland does the buffer management. You can tell Wayland to create surfaces of given dimensions in both sides and a compositor to deal with them, and send commands to the drawing protocol to modify them in the wanted end.
          But considering toolkit's people didn't either use X facilities for that or make their own specification for drawing, chances are there is not enough interest, and it's already running the inefficient way, which means there's no real loss in that aspect from switching to Wayland.
          Last edited by mrugiero; 09 June 2013, 06:59 PM. Reason: Reformulate an ambiguous phrase.

          Comment


          • Originally posted by curaga View Post
            Pango depends on the backend: cairo and FT go to images, Xft backend text.

            Okay, I was wrong here, the popular toolkits don't draw text in a way that could easily pass it forwards.

            However, modifying them to do so is significantly less work than inventing a protocol for each toolkit.
            The question is, why? Why would toolkits want to go back to the old way of doing things, do you think they just one day decided "hey, let's start bypassing the X drawing API for no particular reason"? The reason they stopped using the API is just as valid today as it was then.

            GTK3 already has a HTML5 backend (or it's in development, or something). I'm pretty sure Qt could (if it hasn't already) develop something similar, and EFL as well. There's no point in forcing every app to use some kind of archaic drawing API because what about things like SDL, or apps that only play video and don't need any (or only minimal) UI, or games...? Those would have no need whatsoever to go through the extra overhead of a drawing API. And no matter how you implement it, it's extra overhead, and you'll have to allow direct-rendering in some form or other (in order to allow video playback, among other things), which means, the toolkits would just continue bypassing it and nothing would change.

            Comment


            • Originally posted by curaga View Post
              Please read my original post: http://phoronix.com/forums/showthrea...448#post335448
              It explains why the feature is important. And yes, it's still used.

              Do you agree with the points of my original post?
              No. You didn't explain anything. You just said "it's better" but gave absolutely no explanation as to why, except for an unproven supposition that its faster for scrolling. Seriously, when would it be faster for scrolling, given that not only does the text scroll but image data is also scrolled; even in an editor there's rules and page markers to update, and most webpages and tons of graphics and layout elements in view with the text. The use case you presented for server-side font rendering does not appear to exist, and if it does, you have failed to illustrate it properly.

              Comment


              • Originally posted by curaga View Post
                Proving what? It proves my point that there exists at least one toolkit that does it properly.
                Excuse me my stupidity, but don't they all, in the end, blit to buffer?
                Wayland, in the end, is simply operating with buffers. The whole process happening outside of blitting is not interesting to it, so there is:
                Application "asking"(like in your post) toolkit to do stuff on canvas.
                After this, toolkit handles the buffer to wayland which manages the composition to screen buffer.

                So, only two steps.

                And with X, being "asked" by everyone to do huge amount of things, doesn't exactly this make X to become all-mighty bottleneck?

                We also know, that we can SIMD buffer transfers, but its much harder to SIMD "questions"...?
                Last edited by brosis; 09 June 2013, 08:15 PM.

                Comment


                • Originally posted by Ericg View Post
                  2) Monkey suit? o.O I must have missed that episode
                  Couldn't find the episode but here are the details of the bet.
                  If however, you want a good laugh, this episode has them discussing Mir extensively. The relevant and highly embarrassing bits are between 0:38:00-0:41:30 and 0:54:36-1:04:40. Those guys bought Canonical's PR like the worst Shuttleworth fanboys on omgubuntu.

                  Comment


                  • Originally posted by Serge View Post
                    I was visiting my 58-yo mother for dinner and she plugged her Win7-running laptop into her TV to show us a YouTube video she liked. I guarantee you she did not write any custom configs to get that working.
                    KScreen works automatically without configs too.

                    Comment


                    • Originally posted by Kostas View Post
                      Couldn't find the episode but here are the details of the bet.
                      If however, you want a good laugh, this episode has them discussing Mir extensively. The relevant and highly embarrassing bits are between 0:38:00-0:41:30 and 0:54:36-1:04:40. Those guys bought Canonical's PR like the worst Shuttleworth fanboys on omgubuntu.
                      Oh yeah I remember that episode... LAS should just stick to doing reviews on new distro releases, and stop speculating about display servers, because they're way over their head with that stuff... I know I don't know about the graphics stack all that much either, but then I don't go talking about it on a podcast...

                      Comment

                      Working...
                      X