No announcement yet.

Wayland Becomes A Project

  • Filter
  • Time
  • Show
Clear All
new posts

  • #41
    Originally posted by pingufunkybeat View Post
    Having window management in a separate process is a FEATURE, and not a bug.

    It's the best thing about X, period. I hate unminimiseable and uncloseable zombie windows on that other operating system.

    Window management the X way comes at a cost, which is evident in issues such as rubber-banding when resizing, etc. But it's still very useful.
    Actually, putting the window manager in a separate process complicates things considerably, in the same way that adding multi-threading complicates a program. Now for doing something simple like resizing a window, you have three programs that must coordinate their activity instead of just two. It's a much more complex problem and is part of the reason why resizing apps in X is still slow and laggy even with relatively fast hardware.

    One mistake people keep making with this client-side vs. wm-side window management stuff is differentiating between problems due to that architectural choice, and problems due to other design decisions in the system. Having window managers as separate programs doesn't, for example, solve the issue of programs having different window borders any more than having window management functionality inside the client-side library creates it. Windows could just as easily forbid modifications to the non-client area of a window and that would be that, no more inconsistency.


    • #42
      Originally posted by fabiank22 View Post
      Was were you talking about then? Hurd? What makes Wayland better than X?

      For me the exciting thing is just that it is a viable alternative to X and I think that a "monoculture" always is a bad thing no manner how good that dominant technology is. X and GNU are clearly very dominant technologies among free *nix-like operating systems. That is why I find the LLVM/Clang, Wayland and projects very interesting.


      • #43
        Originally posted by fabiank22 View Post
        How do you know? I mean this thread is pretty much "yay it's new, so it must be better"

        I've read many comments about X being outdated and unmaintainable. But apart from my own experience(the C-Api!) I have yet to see anyone coming up with evidence and or actual knowledge.

        So let's play a game:
        1. Think about a problem you have with X, anything.
        2. Is it an actual X issue or is it a problem with the Kernel, Scheduling or DRM?
        3. Is the issue really X or is it another part of the graphic stack, e.g. Mesa, Gallium, the drivers?
        4. Is it really a problem within X(the infrastructure, Apis, fundamentals) or is it a simple bug/unfinished feature?

        If you still have anything, you may post it here
        Okay, what about this and other problems of X?


        • #44
          Also can I switch GPU on-the-fly in Linux? No, and it's X problem too.


          • #45
            Why do you think it is an X problem ?
            Test signature


            • #46
              Because switch GPU on laptops with Hybrid Graphics requere x server restart.


              • #47
                Switching graphics would require a Windows restart as well if it were not for a massive amount of driver effort to hide that. Note that most modern "X applications" actually use X *and* direct rendered 3D graphics, and the same issue applies on the DRI/DRM side as well.

                It's really not an X issue, in the sense that there is nothing you could do in X that would fully address the problem. All parts of the graphics stack would need significant changes.
                Test signature


                • #48
                  Originally posted by bridgman View Post
                  Switching graphics would require a Windows restart as well
                  For example nVidia Optimus technology doesn't require Windows or Mac OS X restart.


                  • #49
                    Correct, and neither does our Switchable Graphics technology.


                    The point I am trying to make is that these technologies require a large amount of driver development effort, and that work essentially needs to be completely re-done for each supported OS.

                    Many features (such as GL support) can be readily shared across OSes, and this is how proprietary drivers are able to deliver a high degree of functionality to Linux users even though the market size would not normally support that kind of development work. Features like Switchable Graphics, however, can not readily share code across OSes because so much of the work is specific to the OS and graphics stack. That, rather than any inherent shortcoming of X, is the primary reason why you see support on some OSes but not others.
                    Test signature


                    • #50
                      Maybe, but all another X problems (msg #43) is a still X problems.