GTK+ Support Merged For Wayland CSD

[liam]

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.

[bkor]

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.

[runeks]

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.

[F i L]

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.

[jrch2k8]

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