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 curaga View Post
    The only toolkit whose internals I'm familiar with is FLTK. It certainly draws text using the Xft API, not into a picture that is then blitted.
    Xft draws text client-side into a picture, which is then blitted via the XRender API - the text itself is not sent over the wire to the display server, just images.

    I'm not aware of any modern toolkit that sends anything other than images of text to the X server.

    Comment


    • Without DEs?

      1) I have noticed Wayland is not supporting simple WMs like *Box, PekWM, Windowmaker etc. Any fresh info?

      2) How can survive light distros like Crunchbang or Archbang with Wayland as an only display server without X?

      3) What would be productivity gains with Wayland/DE in comparison with WM/X?

      Btw, in my opinion X can fill the task with very limited modules and with very low Xserver activity compared to wayland...

      Comment


      • Originally posted by pjezek View Post
        1) I have noticed Wayland is not supporting simple WMs like *Box, PekWM, Windowmaker etc. Any fresh info?

        2) How can survive light distros like Crunchbang or Archbang with Wayland as an only display server without X?

        3) What would be productivity gains with Wayland/DE in comparison with WM/X?

        Btw, in my opinion X can fill the task with very limited modules and with very low Xserver activity compared to wayland...

        1) You got it a bit wrong i think. The WMs must support the wayland protocol. Not the other way around.

        2) Adapt obviously

        3) You will continue to use your computer the same way you did with X. (as long as whatever you use gets to support the protocol)

        Comment


        • Originally posted by pjezek View Post
          1) I have noticed Wayland is not supporting simple WMs like *Box, PekWM, Windowmaker etc. Any fresh info?

          2) How can survive light distros like Crunchbang or Archbang with Wayland as an only display server without X?

          3) What would be productivity gains with Wayland/DE in comparison with WM/X?

          Btw, in my opinion X can fill the task with very limited modules and with very low Xserver activity compared to wayland...
          There is nothing that precludes lightweight WMs. I think a simple compositor with hooks for a WM would be nice, but I haven't actually done any development with it, only browsed the source.

          Wayland is a nice, simple protocol and can easily outperform X, simply due to the decreased overhead.

          Comment


          • Heya guys / CraigG .

            Just wondering about the multi-monitor and multi-GPU requirement on the clients (and from client's I am taking that as the window-generating component and not the compositor).
            Please bare with me as I only have a preliminary knowledge of this and just want to clean up what I'm reading and understanding.

            So lets treat this as 2 different cases:

            1) Multi-monitor setup.
            A client is expected to listen out for events of new monitors being plugged in, check to see if the total desktop rendering size has increased, etc?
            Are you saying the "window manager" should take care of this (as well as resolution etc)?
            - I would have thought that the compositor should ideally handle the resolution and multi-monitor setup, seeing as how it's combining all of the buffers and sending it to the required GPU to be rendered.
            .... So are you saying that a compositor is a client?

            2) Multi-GPU rendering.
            I can understand that a client may need to specify which GPU to use (as it needs the buffers to render/write into as well as sending EGL code through a specific GPU) - but I wouldn't expect the enumeration to be totally client-side. Shouldn't the compositor list out the enumerated devices along with the versions for the protocols/drivers available?

            So my take away from this is that a display manager should 'manage' things like the multi-monitor and multi-GPU, but hand off the actual work of 'doing things' to the clients.
            I'd like to know what people can say about these.

            --
            old486whizz

            Comment


            • Originally posted by elanthis View 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.
              Compare the size of 1000 words of text, gzip compressed, and then the size of a PNG rendered from that.

              Are you claiming it's not faster to send 1kb vs 500kb of data over the wire?


              For the editor markers, the picture part would only update those parts of the picture, not the full display. For web pages with changing background, the benefit would be less, but unless they have a photograph as their background, it will compress better without text than with.

              Comment


              • Originally posted by brosis View Post
                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"...?
                It's about what goes over the network. Sending a well-compressible background picture, and then a set of text, is better than sending a less-compressible picture due to text blended in.

                X is a bottleneck yes.

                Comment


                • Using this forum page as an example:



                  The background without text compressed to 8.7kb, the background with text compressed to 87kb.
                  The text in this image took 2.3kb uncompressed, 1.2kb compressed with gzip.

                  Sending the plain background + text takes only 11% of the space, resulting in better latency and so usability.

                  Comment


                  • Originally posted by Serge View Post
                    Thank you for taking the time to put together such an informative article and for taking the time to answer questions, Eric and Daniel. I appreciate that the Wayland team have taken a "root causes" approach rather than trying to fix the symptoms of X's shortcomings. Twice this year already I have had to write a custom Xorg.conf to deal with multi-monitor issues. 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. So I am not too eager to defend legacy X. I am just concerned that Wayland's minimalistic approach may create additional problems that do not exist with X. Thus, my questions are:

                    1) With the clients being responsible for more, is there a danger of increased inconsistency in how everything is drawn? There are already some issues with programs written against Qt running in a mostly-GTK environment and vice-versa. Is there a possibility of a regression in this regard? Also, will requiring the clients to do more work increase the likelihood of replication of effort on the part of developers?

                    2) We keep hearing about all of X's legacy cruft, and once in a while we are shown examples. But the legacy usage cases that X is required to support, that X can't get rid of because legacy users are stakeholders who get a say in X's development - are these legacy cases compatible with modern usage cases? That is, in other words, do legacy users even benefit from progress made in X targeting modern usage? Is it possible to fork X into legacy use and modern use branches?



                    I am also very interested in a service managers / init systems comparison. Like Candide, I too am interested in more than just boot-up speed (actually, boot-up speed is not very interesting to me at all).
                    I haven't had to touch xorg conf in YEARS even with multi-monitor situations. I have no problems with plugging my laptop into my TV to watch video either, I definitely did not need to touch a xorg conf or anything like that to do any of these things on either of my laptops...

                    Comment


                    • Originally posted by bwat47 View Post
                      I haven't had to touch xorg conf in YEARS even with multi-monitor situations.
                      I have no problems with plugging my laptop into my TV to watch video either, I definitely did not need
                      to touch a xorg conf or anything like that to do any of these things on either of my laptops...
                      Depends. If you're going with RANDR that's perfectly fine and works great.
                      Separate zaphod-like screens must be specified statically in the xorg.conf, AFAIK.

                      Comment

                      Working...
                      X