compiz - Apr 2006 - window decorations explained and how to move forward

The window decoration system in compiz is implemented using a decoration
plugin and a separate window decoration drawing application (a
decorator). The decorator is drawing window decorations to minimal sized
pixmaps. These pixmaps along with sets of coordinates which maps the
pixmaps to windows are communicated back to the decorator plugin through
a property on the client window. The coordinates can be expressed so
generally that it's not very often that the decorator will have to
communicate with the decoration plugin. You can test this by suspending
the decorator process and see that window decorations keep looking OK
while you continue to use compiz. The decoration plugin binds these
pixmaps to textures using EXT_texture_from_pixmap, uses the coordinates
it got from the decorator as texture coordinates and draws these
decorations around windows very efficiently. The decoration plugin
listens for damage events on these pixmaps and makes sure screen regions
are updated as necessary, just like compiz listens to damage events to
regular windows. Hence, the decorator can do animations on the
decorations and the performance will be just as good as for regular
windows. Shadows are done as part of the decorations.

The decoration plugin will create an input-only frame window that
matches the extents of the decorations created by the decorator.

The decorator will likely use a toolkit and can make sure that the look
of the window decorations match the current theme used by the toolkit.
Events generated from the frame window, like a button click on the
titlebar is handled by the decorator and any window manager actions in
response to an event on the frame window is carried out by using EWMH
[1] in a much similar way to how a pager or a task-list works and window
action menus can be created using the toolkit.


Current State

The current gnome-window-decorator implementation contains hard-coded
drawing functions that uses cairo, mostly because this was the fastest
way to get something going. With the presence of libwnck (Window
Navigation Construction Kit) this could be implemented with not much
code.


What's Next

I'd like to move the drawing code out of gnome-window-decorator.c and
make it possible to plug in different drawing implementations. One
drawing implementation that I'd like plug in here is metacity's current
drawing code so that compiz can be used with all existing metacity
themes. However, metacity's theme system is very limited and not design
for what we can do today with compiz. I believe that a new theme system
is necessary. How this theme system should be is currently beyond me,
SVG-based and shared between gtk/qt seems appropriate, though.

Full KDE integration is not a huge leap. We need to get the kde window
decorator in a working state and we need a kde configuration plugin. I'm
hoping that someone would pick up these tasks but if no one does soon
I'll probably do some work on them.

I'm also a long time fan of blackbox WM and creating a blackbox window
decorator that support blackbox themes would be cool. I believe that
much of the code in blackbox is now in a separate library so a big
effort might not be needed to get this working. Same thing can of course
be done with any other WM.


Drop-Shadows

Drop shadows are kind of hard. Ultimate solution would be to have all
drop-shadows done on the fly by the compositor. However, for high
quality shadows like the decorator is doing today that would require
that we run each window through large convolution filter when
compositing. It would give a common look to all applications, which is
desirable. This can be done on the latest generations of graphics
hardware but it's definitely not for free, it slows things down
noticeably.

I think that the best way to go in the nearest future is to have drop
shadows part of the window decorations as done in gnome-window-decorator
today. However, that only works for rectangular windows. Non-rectangular
windows will have to draw their own drop-shadows. To get a common look
for all applications, some hints on the root window could be used to
describe the selected shadow. An utility library that would keep track
of these properties and help with generating shadows would be very
useful and the decorator would also use this library.

Thoughts?

I'll probably put some, if not all, of this on the compiz page I just
created on freedektop wiki (http://www.freedesktop.org/Software/Compiz).

...and welcome to the compiz mailing list.

-David

[1] http://www.freedesktop.org/wiki/Standards_2fwm_2dspec

Here are some unqualified opinions :) Don't worry, after today I will 
run out of time and only be an observer ...

David Reveman wrote:
> The window decoration system in compiz is implemented using a decoration
> plugin and a separate window decoration drawing application (a
> decorator).
Out of curiosity why is the decorator out of process rather than being 
an integral part of the decorator plugin itself?
> I'd like to move the drawing code out of gnome-window-decorator.c and
> make it possible to plug in different drawing implementations. 
As there is nothing gnome specific about metacity themes, does it really 
make sense for this to be "gnome-window-decorator"?
> One drawing implementation that I'd like plug in here is metacity's
current
> drawing code so that compiz can be used with all existing metacity
> themes. However, metacity's theme system is very limited and not design
> for what we can do today with compiz. I believe that a new theme system
> is necessary. How this theme system should be is currently beyond me,
> SVG-based and shared between gtk/qt seems appropriate, though.
Well, it's easy to say we can do better, but I think it'd be better to 
leave this until people have come up with alternatives to the boring 
strip along the top. Otherwise we just end up with a slower way to draw 
title bars.
> I'm also a long time fan of blackbox WM 
What, not Waimae? Yeah some of us remember that ;) I even remember 
people wondering where you had gone and what was going to happen with 
it. "Where is David? Was he hit by a bus?" :p
> I'll probably put some, if not all, of this on the compiz page I just
> created on freedektop wiki (http://www.freedesktop.org/Software/Compiz).
You may wish to check the writing plugin HTML page into CVS, so other 
people can find it more easily.

And finally, on a mildly related note, Xgl is currently eating a quarter 
of my system RAM. I know it's time to upgrade - can't run 2006 
technology on a box from '99 for sure - but is Xgl compressing the 
pixmaps like MacOS X does?

thanks -mike

Hi David,

Thanks for your explanation! The lack of good documentation of how
compiz works makes it hard to do things.
> What's Next
>
> I'd like to move the drawing code out of gnome-window-decorator.c and
> make it possible to plug in different drawing implementations.
MacSlow, QuinnStorm and myself thought about this just two days ago. My
idea is basically the same as yours and we all agreed it being a good
way to do theming of the window decorations.
We also decided that we should try to merge kde-window-decorator and
gnome-window-decorator if possible.

During the week nothing happened on CVS (we fancied you were on
vacation), I decided to look at the window decorator code (your
explanation saved me a lot of time, I think) and start working on
theming. If I understood Quinn correctly, she wanted to start with a
simple plugin interface based on the code that exists for compiz plugins
and mimic the current behaviour with a plugin. I'm not sure if she
really started doing this, she maybe has other things to do.
> Drop-Shadows
> [...]
>
> Thoughts?
If I remember correctly, MacSlow wanted to do a dropshadow plugin. I'm
not sure if he wants to use the composite manager, though (I'll point
him to this ML so he can say something about it).
If it turns out that MacSlow's implementation is too slow and that a
decoration-based shadow would be faster, we could maybe introduce a new
property to the window that applications with an arbitrary shape could
set. If the property is set, the decorator uses the composite manager to
draw the shadow, if it's not set, we use the fast shadows from the
decorator.


Regards
Thomas



-- 
This email is digitally signed and encoded in PGP/MIME format.
If you prefer encrypted correspondence or if you want to verify my
signature, please ask me for my public key PRIOR to any other response
to this email.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 254 bytes
Desc: OpenPGP digital signature
Url :
http://lists.freedesktop.org/archives/compiz/attachments/20060402/dc75c735/signature-0001.pgp

--- David Reveman <davidr at novell.com > wrote: 
>I believe that a new theme system 
>is necessary. How this theme system should 
>be is currently beyond me, 
>SVG-based and shared between gtk/qt seems 
>appropriate, though. 
 
>Full KDE integration is not a huge leap. 
>We need to get the kde window 
>decorator in a working state and we need a 
>kde configuration plugin. 
 
Sandro Giessl, author of KDE's Plastik theme, is
working on a new SVG-based theme library called
CoKoon: 
 
http://websvn.kde.org/branches/work/kde4/playground/artwork/cokoon/

 
Perhaps this can be used with Compiz? 
 
-Mark