A debian user noticed that compositing was quite slow in beta2 while it was really fast in beta1. The open bug on debian BTS is at: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=380639 I'll ask the reporter to follow the bug here and to give some more informations about his config etc.. Regards,
Created attachment 694 Xorg configuration file
Created attachment 695 Xorg logfile
No idea if this is related (not enough information already in the bug report)... I've noticed some slowdowns affecting the desktop after a while: symptoms include effects such as slow rendering in xterms. Disabling the compositor or restarting xfwm4 (svn HEAD) is enough to restore things. I wonder if some list's growing quite long?
The compositor in beta 2 is more optimized than the one in beta 1. It also features new features such as translucent inactive windows that slow things down dramatically because all windows in the stack have to be rendered (being translucent). So make sure transparency of inactive windows is set to opaque. Also, the use of transparent windows during move requires a lot of computation for render. I dunno about EXA (used by the open source driver for ATI IIRC), but that works just fine with hardware accelerated render on NVidia. As for a leak as mentionned by Daren, well, I'm not seeing any leak as reported by xrestop. Anyway, please update to the latest SVN.
> So make sure transparency of inactive windows is set to opaque. It is. > Also, the use of transparent windows during move requires a lot of computation for render. But why was beta 1 with the compositor enabled as fast as without it, then? > I dunno about EXA (used by the open source driver for ATI IIRC), but that works just fine with hardware accelerated render on NVidia. As I said, EXA gave me a recognizable performance boost when I used the first beta but now it’s gone. > Anyway, please update to the latest SVN. I’ll have to wait until a new upstream version reaches the Debian repositories.
(In reply to comment #6) > > Also, the use of transparent windows during move requires a lot of computation for render. > > But why was beta 1 with the compositor enabled as fast as without it, then? I don't know, I see no speed difference here, neither with the open source nv driver (equally really slow in both cases) or with closed source nvidia driver (really fast in both cases) > As I said, EXA gave me a recognizable performance boost when I used the first > beta but now it’s gone. The main change is a better the use of XServerRegions and clipping, so maybe EXA doesn't like that, or maybe it's something else that EXA doesn't like, but from what I see, beta 2 is at least as fast as beta1 and probably faster. > I’ll have to wait until a new upstream version reaches the Debian > repositories. I'm affraid that's not a good solution, we have no control of when Debian builds its package, so waiting for a release to test a fix is useless. You could build from the source and test directly from within the source ithout installing. It's how I tried both beta1 and beta2 without even restarting the whole session, just restarting just the window manager.
> You could build from the source and test directly from within the source ithout installing. Alright. I got the latest SVN snapshot and ran ./autogen.sh but I got the following complaint: checking for libxfce4mcs-client-1.0 >= 4.3.90.2... not found *** The required package libxfce4mcs-client-1.0 was not found on your system. *** Please install libxfce4mcs-client-1.0 (atleast version 4.3.90.2) or adjust *** the PKG_CONFIG_PATH environment variable if you *** installed the package in a nonstandard prefix so that *** pkg-config is able to find it. But this must be wrong, because I have libxfce4mcs-client3 (version 4.3.90.2-1) installed. What should I set PKG_CONFIG_PATH to? And in fact a »pkg-config --list-all | grep libxfce4mcs*« returns nothing.
I guess you need to install the devel packages too.
Once you have the devel packages installed, use: ./autogen.sh --prefix=/usr --sysconfdir=/etc --datadir=/usr/share --localstatedir=/var As it's where the default debian package should install things. It's important especially if you don't install the binary so that the build can find the previously installed resources such as themes and default config files.
> I guess you need to install the devel packages too. My bad. They were not installed although I thought they were. Now I got it compiled. And thanks to the autogen.sh arguments it seem to have found its defaults file, but I cannot start the freshly compiled xfwm4: $ ./src/xfwm4 missing value for option maximized_offset missing value for option unredirect_overlays ** (xfwm4:9758): WARNING **: Missing values in defaults file ** (xfwm4:9758): WARNING **: Missing data from default files Should I add this options to my local defaults file and with which values, if?
(In reply to comment #11) > Should I add this options to my local defaults file and with which values, if? Oh yeah, sure, Please add: maximized_offset=0 unredirect_overlays=false to $HOME/.config/xfce4/xfwm4/xfwm4rc While you're at it, you may want to build beta1 the same way so you can try all versions without restarting anything... Thanks for your help.
Alright, update: I built the latest snapshot but saw no difference; it was exactly as slow as my currently installed build. After that I did checkout the last snapshot from the first beta and built that one too. And as expected is this one as fast as I am used to it. I can do some more experiments regarding XAA ↔ EXA with activated compositor, but for me the second beta is definitely slower than the first one.
Ok, I'm clueless. One of the difference between beta 1 and beta 2 is the use of XCompositeNameWindowPixmap(). Try this, edit src/compositor.c and add the 2 lines #undef HAVE_NAME_WINDOW_PIXMAP #define HAVE_NAME_WINDOW_PIXMAP 0 right after the includes: #include <X11/extensions/Xcomposite.h> #include <X11/extensions/Xdamage.h> #include <X11/extensions/Xrender.h> then rebuild and try...
I forgot to mention that I had to edit all Makefiles in the snapshot for the first beta because the way the values were assigned to ALL_LINGUAS seemed to be wrong. Instead of multiple lines I arranged the languages in one line only. After that I was able to compile. > Try this, edit src/compositor.c and add the 2 lines […] Since I didn’t know if I had to try this on the first or the second beta, I just tried it on both. And the result is equal: no difference.
Can you try this build: http://www.foo-projects.org/~olivier/preview/xfwm4-4.3.90.2-test-bug-2099.tar.bz2
> Can you try this build: > > http://www.foo-projects.org/~olivier/preview/xfwm4-4.3.90.2-test-bug-2099.tar.bz2 Works exactly as the first beta, which means: this one is fast again.
Ok, a more polished version has been committed as revision r22814. A snapshot is available from http://www.foo-projects.org/~olivier/preview/xfwm4-4.3.90.2-r22814.tar.bz2 If you can confirm that still perform fast on your system, then the bug will be marked as fixed.
> Ok, a more polished version has been committed as revision r22814. > > A snapshot is available from > http://www.foo-projects.org/~olivier/preview/xfwm4-4.3.90.2-r22814.tar.bz2 Works like a charm. > If you can confirm that still perform fast on your system, then the bug will be marked as fixed. Please feel free to do so. Thanks for everything.
Ok, resoving bug. I've posted to Xorg ML to see if I get some insights on why we get that slowdown when using clipping. We'll see. Thanks.
Some odd addition: when moving windows around, they are slow at the moment, just like I reported. But when I change to another Terminal via [AltGr]+[Strg][Fn] and return to the Terminal running X, the windows move a lot faster. (I’d say as fast as in Beta 1.) Any ideas how to explain this strange behaviour?
Nope, could be an issue with EXA maybe? I don't see anything that could explain that in xfwm4 compositor code, though.
> Nope, could be an issue with EXA maybe? Any ideas how I could get any useable output to log? Should I post on one of the X.org MLs and ask for clarification? > I don't see anything that could explain that in xfwm4 compositor code, though. Yes, I thought so. If I find time I will test if the same happens using xcompmgr on other DEs. This is really strange.
I tested GNOME with xcompmgr now and even there the movement of windows is a little bit smoother after the terminal switching, altough not as much as with xfwm4’s compositor. I think the latter has a more perfomant implementation.