Announcement

Collapse
No announcement yet.

GTK+ Support Merged For Wayland CSD

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

  • #16
    Originally posted by Ancurio View Post
    That's a great idea! Can we have a link to your repo with the initial code?
    I'd be interested to see how you implemented this library.
    Could probably re-use much of the code from XWayland.

    Comment


    • #17
      Yop

      Originally posted by Ancurio View Post
      Say goodbye to Xorg and hello to driver wars as the blob vendors will now have to support two instead of one platform.

      Mir is basically the same as Wayland, which Mir developers admitted themselves.
      The only difference is the shell implementation, and the fact that Canonical has full control over the project.
      +1

      I just don't know where these people get the confidence about AMD/Nvidia and their will to support every shitty display server community throw at them...

      Comment


      • #18
        Originally posted by newwen View Post
        The good thing about Mir is that competition is stirring up wayland development and we could say goodbye to Xorg sooner than we think.
        This support mentioned in this article is the result of a lot of slow work over a long period. Is a post like this going to appear every-time something get's improved Wayland support simply because of all of the FUD floating around about Wayland being vaporware? They have been developing it for years yes, but they have actually been developing it in that time. This idea that Mir shook them out of some lazy complacency is asinine: at best it just forcing people to make their intentions known about it.

        Comment


        • #19
          Originally posted by newwen View Post
          The good thing about Mir is that competition is stirring up wayland development and we could say goodbye to Xorg sooner than we think. Specially if Nvidia and Amd provide us with EGL platform drivers.
          I reallly wish someone would explain to me how mir is competing. How is it different other than its lack of functionality?

          Comment


          • #20
            Originally posted by liam View Post
            I reallly wish someone would explain to me how mir is competing. How is it different other than its lack of functionality?
            Its the same issue the gnome guys addressed. Everyone knew Wayland would happen "Eventually" but they werent really pushing because there was no downside to NOT. they were no competitors or alternatives or anything, so the wayland guys and gnome and kde could just chill and do whatever.

            Now Mir's here and its the classic example of "We're gonna try harder and win just to give a 'screw you!' to the other guys." So now Wayland development and Wayland-enablement has kicked up

            Comment


            • #21
              Originally posted by Ericg View Post
              Its the same issue the gnome guys addressed. Everyone knew Wayland would happen "Eventually" but they werent really pushing because there was no downside to NOT. they were no competitors or alternatives or anything, so the wayland guys and gnome and kde could just chill and do whatever.

              Now Mir's here and its the classic example of "We're gonna try harder and win just to give a 'screw you!' to the other guys." So now Wayland development and Wayland-enablement has kicked up
              That might make sense if it were true.
              http://cgit.freedesktop.org/wayland/wayland/log/
              Do you see how active they were leading up to the 1.0 freeze?
              If you look at bit more (back to June) you'll see some of the input work daniels has been working on.
              Now, if that wasn't fast enough for Canonical they could get off their @$$3$ and help.
              From the back and forths I've read on G+ and irc, I don't have much confidence that the Mir devs are going think of a single thing that the Wayland devs haven't already considered. It is this later part that confuses me the most when I hear Ubuntuboosters talk about the power of competition. It's only useful when the other team actually has something they can field.

              Comment


              • #22
                Originally posted by Ericg View Post
                Its the same issue the gnome guys addressed. Everyone knew Wayland would happen "Eventually" but they werent really pushing because there was no downside to NOT. they were no competitors or alternatives or anything, so the wayland guys and gnome and kde could just chill and do whatever.

                Now Mir's here and its the classic example of "We're gonna try harder and win just to give a 'screw you!' to the other guys." So now Wayland development and Wayland-enablement has kicked up
                A GNOME release team person here: Mir has not speeded up anything. Please stop this bullshit asap. The only thing it did was explain why Canonical did not move ahead or help out Wayland, despite public commitment. As a result, we know we have to do the work we were expecting from Canonical as well too.

                Comment


                • #23
                  Originally posted by F i L View Post
                  One of the reasons is effects quality I believe. With CSD you have one buffer which holds your entire window's contents, including window decorations. The compositor (Wayland) can then transform/warp/etc your window however it wants (for all those pretty Compiz-like effects) without doing to much special stuff to get rid of the aliasing between the window contents and decorations.

                  There may be other, more technical reasons for it, but I'm unaware of them. Also, as someone else mentioned, Wayland can do both.
                  Another thing it provides is simply speed. Having it all in one buffer/texture means not having to do additional copying, as opposed to if you receive the decorations and client surface in two distinct buffers. This speeds up everything, and is valuable especially for lower end hardware.
                  Last edited by runeks; 03-20-2013, 11:36 AM.

                  Comment


                  • #24
                    Originally posted by runeks View Post
                    Another thing it provides is simply speed. Having it all in one buffer/texture means not having to do additional copying, as opposed to if you receive the decorations and client surface in two distinct buffers. This speeds up everything, and is valuable especially for lower end hardware.
                    Yes I was thinking about that last night actually. If the window decorations require their own buffer (this size of the window-contents + decoration padding) then not only are you wasting time blitting the content texture over, but it also requires more than double the amount of video memory per window. Uncompressed texture memory isn't cheap, so not only does CSD simplify the DS protocol, it also means better speed and less memory consumption.

                    There IS an alternative though (i think)... when the client requires a Window at say 800x600 the server actually makes a buffer that size plus the size required for decorations, then the client receives and "contents rect" which is an offset region in the surface at the requested size (800x600) the client can draw into. Of course there will probably a whole crop of other problems that come with that, not the least of which would be efficiently synchronizing when/how the client and server draw into the shared buffer.

                    Another cool thing about CSD is that, in theory, both KDE apps and GTK apps could look as intended regardless of the WM.

                    Comment


                    • #25
                      Originally posted by F i L View Post
                      Yes I was thinking about that last night actually. If the window decorations require their own buffer (this size of the window-contents + decoration padding) then not only are you wasting time blitting the content texture over, but it also requires more than double the amount of video memory per window. Uncompressed texture memory isn't cheap, so not only does CSD simplify the DS protocol, it also means better speed and less memory consumption.

                      There IS an alternative though (i think)... when the client requires a Window at say 800x600 the server actually makes a buffer that size plus the size required for decorations, then the client receives and "contents rect" which is an offset region in the surface at the requested size (800x600) the client can draw into. Of course there will probably a whole crop of other problems that come with that, not the least of which would be efficiently synchronizing when/how the client and server draw into the shared buffer.

                      Another cool thing about CSD is that, in theory, both KDE apps and GTK apps could look as intended regardless of the WM.
                      yeap and additionally i think you have an alternate method that can speed things up a bit since the WM actually is awere of the dimensions of the Decoration theme it can actually allocate once every part of the theme on FB memory and pad the target surface before it gets to render stage, so once the surface reach the render stage the decoration can be composited in the padding area cloning/referencing those memory regions previously allocated saving some memory and maintaning the concept of a fully integrated surface (context+decoration)

                      in fact with wayland is possible the option of having all apps use the active theme regardless of the DE enviroment/Toolkit if Qt and Gtk agree in an interoperable theme engine format (ofc that would bring the question, why keep both then?)

                      Comment

                      Working...
                      X