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