Announcement

Collapse
No announcement yet.

The Wayland Situation: Facts About X vs. Wayland

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

  • Clarification on server-side vs. client-side allocation?

    I found here a comment by daniels mentioning the server-side vs. client-side querelle between wayland and mir. Later in the thread it is said that the difference between the two has considerable implications in terms of energy consumption.

    Is there anybody that could explain why is so, and what is the rationale behing wayland choosing to be agnostic?

    Thanks!

    Comment


    • Some facts for you, before you shoot each other:
      X.org is dead end.
      Wayland is future.
      Wayland is developed by Xorg developers.
      Use some benchmarks instead of building theories - test Xorg with Xrender vs Wayland. Xorg with pixmap test is useless. Post results.
      If you find performance of Wayland lacking, post suggestions.
      If you think that Xorg is enough, stay with Xorg, but understand that you will have to move to Wayland with newer application versions, so better do as suggested above instead.

      This is turning into religious war (as in fighting over personal beliefs).

      Comment


      • Originally posted by renox View Post
        You can but it adds latency, not an issue with pre-recorded movie, not so good for a GUI.
        Teamviewer works just fine. Removal of huge bottlenecks of X improves latency.

        Originally posted by renox View Post
        Link? Besides it doesn't help for scrolling text.
        How much is needed to resend when scrolling within X session? Whole window (with all parent subwindows).
        You see, it does help.

        Originally posted by renox View Post
        So you have (1) a program running on the CPU, sending instructions to render buffer on the GPU, then a special pass on the GPU to compress the frames (just doubled GPU memory usage BTW) then re-reading the GPU memory to be able to send it through the Ethernet card instead of having (2) a program sending directly the drawing command to the Ethernet card, that is progress to you?
        (1) make sense when you want to do complicated stuff, but for drawing text (which is still a very important part of the desktop), this is a regression: it adds latency, increase bandwith usage for nothing.
        X will send instructions to render buffer on GPU as well.
        It will also mirror calls over network. Remote X will also have to plot (CPU), then also render this buffer to remote GPU.
        Bandwidth usage is also playground for a lot of assumptions - Wayland can easily use less bandwidth than Xorg, except one (where, I theoretically agree) has solid background with a lot of text - why not use simple console ssh instead? - even more efficient.
        Also, network bandwidth is by far not highest priority - Xorg will use more resources to actually plot the received data (multiply by window chaos mentioned in the article).
        Please read my message above, this talk is trash talk - it has no practical interest to anyone, in essence you(people) flood the thread instead of asking questions to developers... practice always wins over theories.
        You should also be able to run Xorg server connected to Wayland machine hosting Xorg client, that receives data.. theoretically. So a lot of possiblities to find truth via testing and not talking.

        One of the reasons I tend to *think* Wayland is more even network efficient, is the possibility to send draw calls from (application to toolkit) over network within individual surface(buffer, window).
        These calls may be received by client and sent to local toolkit, which then will plot buffer locally and send it to local Wayland.
        So, instead of sending already plotted buffers, higher communication calls are transmitted, ie sending plotting commands to toolkits.
        But Wayland developers did not use it. I *think* there was a reason and case was already tested. Possible indication was already mentioned in article plotting of font, where call and information to plot takes much more bandwidth than font as bitmap itself.

        I also see this whole discussion similar to useless vector vs bitmap fight. When we have huge monitors (plotting area) and very simple geometric figures, vector will win. But otherwise it will be equal or loose. What is more efficient to send over network? I think bitmap, because modern toolkits don't plot simple geometry anymore.
        brosis
        Senior Member
        Last edited by brosis; 11 June 2013, 07:43 PM.

        Comment


        • Originally posted by Candide View Post
          I know that I certainly would be. Not just to judge the performance (boot itmes) of these three competitors, but to understand what they can do for stability and security.

          Thanks for asking Eric.
          To correct a common misconception, the init system itself really implies very little for boot times, so long as it supports parallelization (which systemd and upstart both do). It's how the actual services that are being started are optimized that affects boot time. If you set out to optimize the boot time of any current mainstream Linux distro, you would not - if you were sensible - do so by re-writing the init system. systemd was never primarily about improving boot speed.

          Comment


          • Originally posted by garegin View Post
            I'm talking about the http://en.wikipedia.org/wiki/Desktop_Window_Manager. And yet applications from before that weren't designed with DWM in mind still can work (some don't obviously), whereas in linux you have to port your application to a toolkit that supports wayland.
            As long as the API and the calling conventions keeps stable (if someone is better informed on ABI compatibility, please correct me, I think I might be leaving some variables out of the picture), software should be compatible. Since people don't usually write for whatever windowing infrastructure there is in Windows, but for the win32 API or for MFC, you have no knowledge of what happens under the hood. It's nothing but abstracting the implementation. Even when the windowing system changes, MS takes the work of maintaining a stable API, avoiding the erase of deprecated functions. Most of them, if not needed anymore, become wrappers around the new versions, so your app keeps working.
            If you use only the toolkits without direct access to the X protocol, when the toolkit gets ported, you'll need at most to recompile for porting to Wayland. Windows does the port of the Win32 API in house, because of obvious reasons. In the open community case you can not expect that Wayland programmers port the toolkit. Even in MS is unlikely that the same people in charge of the low level windowing system takes care of the exposed API, but there are probably specific programmers in charge of that area.
            And in the case of particular apps, it's a design choice. If you want your app to be toolkit agnostic, you should target Xlib or XCB, but you'll need porting to support Wayland. If you are going to use a toolkit, it's better to only use toolkit calls.

            Comment


            • Originally posted by garegin View Post
              I'm talking about the http://en.wikipedia.org/wiki/Desktop_Window_Manager. And yet applications from before that weren't designed with DWM in mind still can work (some don't obviously), whereas in linux you have to port your application to a toolkit that supports wayland.
              Well, no, you don't, it just runs through XWayland. Which is exactly the backwards compatibility layer you seem to be under the impression doesn't exist.

              Comment


              • X) Everything is a window to X, there's no different window types, its just “A window.”

                A) Your screensaver? Its a window that told X:
                1) Put me above all other windows, at all times.
                2) Make me fullscreen.
                3) Give me all input.

                B) A pop up window? Its a window that told X:
                1) Put me RIGHT HERE.
                2) Give me all input.

                C) Problem? For one: they clash. Your screensaver won't activate while a pop-up window is up because they conflict.

                D) Your screensaver, and screenlocker, probably didn't hook into all the necessary libraries to understand media keys... the problem there is when you're working at home listening to some music, you get up to leave, close the lid and head out. Laptop's asleep, screensaver is the 'active' window. As soon as you open the lid up, your music kicks back in, blaring out of your speakers and its just easier for you to close the lid again and deal with it later rather than scramble to put in your password, open the media player and pause it, or hit mute.

                E) The developers tried to fix it. They specced out an extension, had the theory ready. But when it came time to implement it, they realized it would break the X Model too badly. This has been broken for 26yrs, and its going to STAY broken. Enjoy.
                Thanks for the info I wasnt aware that X was the cause of all these issues (that affect me regularly). Tear free graphics is great but I must say these fixes have me a lot more interested in Wayland than I was previously. These issues are to me one of the last very obvious flaws with the Linux desktop, it makes me shake my head everytime I come back to my machine and close a dialog then suddenly the screensaver pops up and prompts me for my password.

                As to all the hysteria over Wayland this is to be expected with any major change. I suspect once we are actually able to use it most concerns will go away. As they say seeing is believing.
                timothyja
                Senior Member
                Last edited by timothyja; 11 June 2013, 09:36 PM.

                Comment


                • Originally posted by mrugiero View Post
                  As long as the API and the calling conventions keeps stable (if someone is better informed on ABI compatibility, please correct me, I think I might be leaving some variables out of the picture), software should be compatible. Since people don't usually write for whatever windowing infrastructure there is in Windows, but for the win32 API or for MFC, you have no knowledge of what happens under the hood. It's nothing but abstracting the implementation. Even when the windowing system changes, MS takes the work of maintaining a stable API, avoiding the erase of deprecated functions. Most of them, if not needed anymore, become wrappers around the new versions, so your app keeps working.
                  If you use only the toolkits without direct access to the X protocol, when the toolkit gets ported, you'll need at most to recompile for porting to Wayland. Windows does the port of the Win32 API in house, because of obvious reasons. In the open community case you can not expect that Wayland programmers port the toolkit. Even in MS is unlikely that the same people in charge of the low level windowing system takes care of the exposed API, but there are probably specific programmers in charge of that area.
                  And in the case of particular apps, it's a design choice. If you want your app to be toolkit agnostic, you should target Xlib or XCB, but you'll need porting to support Wayland. If you are going to use a toolkit, it's better to only use toolkit calls.
                  Can you please stop posting crap about windows and ms, because its completely unrelated off-topic flood?!

                  If one uses only toolkit and library, nothing needs to be recompiled, except toolkit for new version and new flag. Unless toolkit breaks ABI. Which will be in changelog. Of which no one from end-user perspective cares, because its easy to recompile in source based or make new package.

                  There is already some work happening between major library and toolkit developers and wayland developers. Those who don't do the homework, can run easily off the Xwayland.

                  Comment


                  • Originally posted by brosis View Post
                    Can you please stop posting crap about windows and ms, because its completely unrelated off-topic flood?!

                    If one uses only toolkit and library, nothing needs to be recompiled, except toolkit for new version and new flag. Unless toolkit breaks ABI. Which will be in changelog. Of which no one from end-user perspective cares, because its easy to recompile in source based or make new package.

                    There is already some work happening between major library and toolkit developers and wayland developers. Those who don't do the homework, can run easily off the Xwayland.
                    I'm posting because there is someone asking about it.
                    And I stated that. I said "AT MOST". I wasn't talking exclusively about Windows in that ocassion. The reason I gave is obviously valid for the cases I enumerated later.
                    And it's relevant because the question is relevant, it's comparing because someone doesn't understand why one breaks compatibility and the other doesn't.
                    Also, I never stated anything about being hard to recompile, I'm aware that it's easy. I compile things at least twice a day, to test some toy projects of my own.

                    And, obviously, since there's already awareness of Xwayland, the porting we talk about is to NOT use Xwayland. To avoid an extra, unneeded, client.

                    Comment


                    • Originally posted by bwat47 View Post
                      I'm not really familiar with how these windows internals works, but perhaps windows has some sort of seamless backwards compatability that allows this, like wayland has with xwayland?
                      Sort of, yeah. Applications run in different "profiles" which alters how things work in various ways. It's similar to the kernel personalities in BSD and the like which allow for Linux binaries to run unaltered, but it extends down to the library level as well, similar vaguely to how glibc adds extra mangling to some symbol names so that old binaries using "fstat" or the like get a result laid for 32-bit size values but all newer binaries compiled against newer headers get 64-bit-friendly layouts. Essentially apps run in a "container" of sorts that acts more like an older edition of the OS from top to bottom.

                      What Linux can learn from this, I don't know. The Windows solution is horrible in a lot of ways (other than that It Works). Trying to wrap your head around WoW64 or the like is just a pain compared to the common Linux bi-arch or multi-arch setup, and XWayland is a much cleaner and easier concept to grok than "compatibility mode." The Linux way has its own annoyances, but excels in some areas. Whether or not some hybrid approach is even better we may well never know.

                      I'm unsure how OSX deals with such things. I think it's closer to Linux, though.

                      Comment

                      Working...
                      X