! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
xfwm4 compositor is slightly slower in beta2 than in beta1
Status:
RESOLVED: FIXED

Comments

Description Yves-Alexis Perez editbugs 2006-07-31 14:23:11 CEST
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,
Comment 1 Mathias Brodala 2006-07-31 15:20:17 CEST
Created attachment 694 
Xorg configuration file
Comment 2 Mathias Brodala 2006-07-31 15:20:47 CEST
Created attachment 695 
Xorg logfile
Comment 3 Mathias Brodala 2006-07-31 15:23:23 CEST
 
Comment 4 Darren Salt 2006-08-01 03:25:57 CEST
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?
Comment 5 Olivier Fourdan editbugs 2006-08-15 16:12:16 CEST
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.
Comment 6 Mathias Brodala 2006-08-15 16:21:34 CEST
> 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.
Comment 7 Olivier Fourdan editbugs 2006-08-15 17:54:25 CEST
(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.
Comment 8 Mathias Brodala 2006-08-15 18:24:38 CEST
> 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.
Comment 9 Olivier Fourdan editbugs 2006-08-15 19:26:09 CEST
I guess you need to install the devel packages too.
Comment 10 Olivier Fourdan editbugs 2006-08-15 19:28:48 CEST
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.
Comment 11 Mathias Brodala 2006-08-15 20:30:20 CEST
> 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?
Comment 12 Olivier Fourdan editbugs 2006-08-15 20:45:37 CEST
(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.
Comment 13 Mathias Brodala 2006-08-16 19:33:04 CEST
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.
Comment 14 Olivier Fourdan editbugs 2006-08-16 19:55:25 CEST
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...
Comment 15 Mathias Brodala 2006-08-16 20:15:32 CEST
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.
Comment 16 Olivier Fourdan editbugs 2006-08-17 20:20:56 CEST
Can you try this build:

http://www.foo-projects.org/~olivier/preview/xfwm4-4.3.90.2-test-bug-2099.tar.bz2
Comment 17 Mathias Brodala 2006-08-17 20:44:44 CEST
> 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.
Comment 18 Olivier Fourdan editbugs 2006-08-17 21:52:37 CEST
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.
Comment 19 Mathias Brodala 2006-08-17 22:42:12 CEST
> 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.
Comment 20 Olivier Fourdan editbugs 2006-08-18 05:45:22 CEST
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.
Comment 21 Mathias Brodala 2006-09-05 01:02:40 CEST
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?
Comment 22 Olivier Fourdan editbugs 2006-09-05 19:12:51 CEST
Nope, could be an issue with EXA maybe? I don't see anything that could explain that in xfwm4 compositor code, though.
Comment 23 Mathias Brodala 2006-09-05 21:34:25 CEST
> 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.
Comment 24 Mathias Brodala 2006-09-06 00:20:41 CEST
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.

Bug #2099

Reported by:
Yves-Alexis Perez
Reported on: 2006-07-31
Last modified on: 2009-07-14

People

Assignee:
Olivier Fourdan
CC List:
1 user

Version

Attachments

Xorg configuration file (3.19 KB, text/plain)
2006-07-31 15:20 CEST , Mathias Brodala
no flags
Xorg logfile (49.91 KB, text/plain)
2006-07-31 15:20 CEST , Mathias Brodala
no flags

Additional information