Page 3 of 3 FirstFirst 123
Results 21 to 25 of 25

Thread: GTK+ Support Merged For Wayland CSD

  1. #21
    Join Date
    Jan 2009
    Posts
    1,435

    Default

    Quote 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.

  2. #22
    Join Date
    Jul 2012
    Posts
    287

    Default

    Quote 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.

  3. #23
    Join Date
    Aug 2010
    Location
    Denmark
    Posts
    142

    Default

    Quote 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 at 11:36 AM.

  4. #24
    Join Date
    May 2012
    Location
    Sunshine State
    Posts
    307

    Default

    Quote 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.

  5. #25
    Join Date
    Jun 2009
    Posts
    1,168

    Default

    Quote 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?)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •