[compiz] window decorations explained and how to move forward

[David Reveman]

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