[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kwin
Subject:    Compositing manager
From:       Lubos Lunak <l.lunak () suse ! cz>
Date:       2006-07-14 14:46:32
Message-ID: 200607141646.32460.l.lunak () suse ! cz
[Download RAW message or body]


 Hello. Ok, to whoever is interested:

 As already mentioned, the plan for KDE4 is to create a built-in compositing 
manager directly in KWin instead of a separate one like Kompmgr in KDE3. 
There's already a branch which has some experimental code in 
svn.kde.org/home/kde/branches/work/kwin_composite . The code is not 
completely done, but it's usable. The only thing seriously needing work is 
the actual compositing and painting.

 I've already tried a bit and it's obvious I can't do that, so it needs to be 
by somebody else. And I'm rather clueless so my opinion on it doesn't even 
count that much and probably even the compositing code that's there now will 
have to be thrown out completely and redone.


 The plan is roughly like this:

- The compositing and painting can be done as an additional last step. Instead 
of windows being drawn directly the Composite extensions redirects them to 
pixmaps and Damage extensions tell what changes. KWin tracks these changes 
and as a final step does the compositing based on this info. The code is 
mostly in composite.cpp and small parts are spread over the rest.

- The idea is that it would be nice to be able to use either OpenGL or XRender 
depending on the configuration (and capabilities). This should be done by 
different "scene" modules, base class in scene.*, there's currently very 
basic one using core X and there's XRender version. Selecting is currently 
hardcoded in composite.cpp .

- The main function is Scene::paint() which gets a region of areas that need 
repainting and a list of all windows. Other functions are used for informing 
the scene about changes like a window changing geometry.


 The remaining parts of the plan are to whoever is not clueless like me, but 
the following would be nice:

- Effects probably should be plugable. I'm not quite sure about this, I have 
no idea if it won't be too complicated to have the system generic enough and 
if there would be actually people writting them. Compiz is plugable but I 
don't think there are actually many plugins outside the few that it ship 
itself. On the other hand there'd be some hype factor out of this.

- Code doing effects should work with all scenes, at least for simple effects. 
Currently the code in effects.* get a transformation matrix and opacity 
value, both of which it can modify. Making an effect that makes the currently 
moved window transparent is very simple.


 The current XRender scene works like this: SceneXrender::paint() first runs 
all Effect::transformWindow() on every window, to get final transformation, 
so it knows where and how to paint it. Currently only x/y transformation and 
opacity change is supported. Then it uses the damage region and areas of 
opaque windows above for clipping the painting and finally it paints the 
windows. There's the WindowData structure that caches some info about the 
windows.

 It kind of works for this simple case, but it's probably not good design for 
anything better. I don't know how to e.g. add shadows, because they're not 
transformations of the window but something added. As I said, this code can 
be simply dumped if it's too bad. Compiz seems to work by having a first pass 
that finds the final transformation and the second pass of painting seems to 
be actually done by the effects as well. I don't really understand that 
stuff.


 Some final thoughts:

- There's HACKING file in kwin/ having some useful tips.

- The plugins should do only effects and not add functionality like Compiz 
plugins. I don't think exposing all KWin internals to plugins and let them 
mess with it is a good idea.

- For the same reason, compatibility with Compiz plugins doesn't look very 
realistic. Compiz seem to have any plugins interface, it simply exposes all 
internals. Even if I wanted, mapping all this to KWin doesn't look really 
doable. Some reasonable subset might be perhaps doable using a bridge plugin.

- Even things like the Expose effect need support in KWin core. One of the 
reasons is that X currently doesn't have any input redirection, so clicking 
somewhere on the screen sends the click to whatever really is there, not to 
whatever is composed and painted there. It probably should be done by KWin 
doing the Expose functionality itself, creating the necessary thumbnail 
windows and so on and an effect would just create the thumbnails for it.

- There's libcm, a library for compositing used by Metacity 
(http://cvs.gnome.org/viewcvs/libcm/). No idea about it, there's a small 
possibility it could be used or at least have a similar design.


 As for the rest, that's up to whoever decides to code this. I'll of course 
will try to help as possible and so on, so if you have questions, ask.


PS: One more thing. I'll be on vacation for 10 days starting from this Monday, 
so while I'll try to watch this mailing list there may be delays.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/
_______________________________________________
Kwin mailing list
Kwin@kde.org
https://mail.kde.org/mailman/listinfo/kwin
[prev in list] [next in list] [prev in thread] [next in thread]