News from the Wobblyland, part II.
Ok, time for another screenshot. It actually shows most of the recent improvements in kwin_composite:
At the bottom-left there's KWrite with the file dialog open. The dialog is transparent because I have MakeTransparentEffect enabled - it makes moved/resized windows transparent and it also makes dialogs transparent (hey, I need to test the stuff somehow). The KWrite main window is de-saturated and has reduced brightness - that's DialogParentEffect and support for saturation/brightness, patches from Rivo Laks.
Above it is glxgears, the ultimate benchmark ;) , with adjusted transparency. The xterm behind it shows its output, the first three lines are when no compositing is running - this stuff takes quite some resources, just in case somebody believes that calling it "accelerated desktop" makes things faster (hmm, I guess I'll quickly run out of names for this stuff this way).
The performance is not that bad though, as shown by ShowFpsEffect, that small rectangle in the top right corner. The blue bar is frames per second, this GeForce4 laptop has no problem keeping up with the currently hardcoded 50FPS, the green graph running to the right shows time needed to draw recent frames, again the laptop in this picture manages to keep it green with about 7ms per frame, going temporarily to yellow/red/black values only during big changes. This effect is the first one that doesn't just alter drawing attributes but paints directly using OpenGL or XRender depending on the mode (no, the rectangle is actually not really there and no, I still haven't given up on the crazy idea of at least partially supporting XRender too).
And, as it seems I happen to be a lucky exception (even my home GeForce2 doesn't perform that bad), I decided to work on some performance-related parts sooner than I had expected and I've implemented things like partial repaints, support for double-buffered painting with the composite overlay and also SHM mode from Beryl (which in turn has it from Looking Glass - Beryl actually simply calls it non-TFP but KWin already has another non-TFP mode from glcompmgr). As much as I don't get it SHM mode actually slightly outperforms TFP on the average - I guess the texture_from_pixmap extension support in the drivers/X/wherever still needs some work.
Hopefully that improves matters for other people. Oh, that's the one thing that cannot be seen in the picture. Philip Falkner has successfully battled the ATI OpenGL support and KWin is no longer NVidia-only (I have no idea about Intel but it probably should work too, given that it should share some of the problems with ATI like GLX only version 1.2 and not having TFP support in drivers).
Next I'll probably try to improve the window geometry support so that it will be actually possible for all the things to wobble (gee). I'll see, with the openSUSE 10.2 release getting very close. Incidentally, since we've decided there to start Compiz or Kompmgr by default if X is configured to have the necessary support, I finally had a thorough look at Kompmgr while hunting some bugs (yeah, at the time I try to make it permanently obsolete :) ). I'm really glad Thomas Luebking was the hero to take XCompmgr and create Kompmgr - plain C is scary.
What an awesome bunch of things! And usefull too, like the parend / child dialog sdarkening/shading approach. Will be a great help for usability; no more ambiguity about what is blocking the main window.
Forgive the stupid question. When would we see this stuff in the wild, as in "as 'stable' as compiz, but usable" product?
Re: Awesome stuff!
When it's done, maybe a bit sooner or later :). Right now the plan is that it could be usable even for backporting for the next openSUSE release (not 10.2, the next one in about half a year), we'll see. It of course depends on some factors like how many people will work on it or what exactly is considered usable (I'm not quite sure it'll get burning windows by then but most of the useful stuff does not seem to be actually overly technically demanding).
Nice work :-)
What I was wondering, I read somewhere that it should be possible to make some kind of generic system for all the eyecandy, a sort of cross-DE plug-in system.
Is any of that actually going to happen?
So are you just doing this KWin work to make that a possibility or do KDE developers have to make their own copies of the kind of things you now see happening on the Gnome side?
Re: Nice work
I don't know. That was originally part of the idea but the more I look at it the less likely I see that happening. Compiz/Beryl plugins are basically just parts of it moved into a separate library, having full access to almost everything and supporting that in KWin is next to impossible (not to mention crazy). In fact I think even Beryl and Compiz are no longer completely compatible and they don't have a very different design from each other, unlike KWin.
I aim for a nice relatively simple API for effects in KWin, so the possibility of a generic interface is there, but the question is if it would be worth it, technically or just given the effort. After all window managers don't share their decorations code (just like many other different apps don't share many things), so why would they have to share effects?
Also, I don't think Beryl/Compiz are really GNOME side. Beryl seems to have more plugins and it's on neither's side, it's on Beryl's side. Compiz, despite officially being neutral, is GNOME in practice now and I think there are even plans of keeping Metacity as only a legacy window manager considered, but in that case they'll probably have quite some work with adding all the interesting window manager pieces from Metacity to Compiz. Choosing between adding effects to KWin and adding half of KWin to Compiz/Beryl I guess I'll go with keeping the proven one.
Zack Rusin's interview on Linux Links Tech Show (http://dot.kde.org/1163696250/) mentions the same subject - "extending KWin or what?"
His line of thought is the same: there is so much good code in KWin that leaving it behind in favor of some glitzy new WM would be insane. The question is more about how and what is added to Kwin.
He relayed the same general dislike for supporting Beryl plugins outright, as they are too deeply wired into the Beryl and, in addition, may be a security risk.