User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1) Gecko/20061107 BonEcho/2.0 Build Identifier: Using the built-in compositor with xfwm4 causes nice transparency effects, but after an amount of time (usually 48 hours but it could be more or less) window drawing "slows down" and it's like I'm running on a 486 DX2. CPU usage and RAM usage are normal during this time so it's not eating CPU or RAM that I can visually see with top or free. The only real way to fix it is to restart the X server. Sometimes disabling composite in Window Manager Tweaks and reenabling it will solve it but then it might start drawing windows slowly after a few hours of usage. Sometimes disable/renabling compositing doesn't even fix it and an X restart is required. Confirmed on two systems, one 32-bit and the other 64-bit. Both have nVidia cards (5200FX (32-bit), 7900GT (64-bit)) with the latest 9629 driver. This slowdown has happened since the 87xx driver, or since I've started using XFCE 4.4 RC 1. I have contacted nVidia and they didn't believe it was a driver problem. I've been using Beryl for over a week without any slow downs or problems. It seems to be centered on an xfwm4 problem. Reproducible: Always Steps to Reproduce: 1. Enable Composite with xfwm4 2. Run your system non-stop (don't restart X) for a week 3. Actual Results: Slowdown of window drawing. The shadow behind a window will "trail" behind like mouse trails. Other drawing effects like menu selection is noticeably slower than normal. Expected Results: Smooth window drawing no matter how long the system is running. Both systems: Fedora Core 6 latest packages which include Kernel 2.6.18 X.org 7.1
I forgot to add that when I posted this problem initially on the nvnews forum a user mentioned that the latest SVN code doesn't have this problem. I didn't find a bug or any mention of this on the mailing list so I wasn't sure if anyone was even aware of this problem. I haven't tried the latest SVN yet, but if this is recommended then I will try and free up some time to compile for a few hours... http://www.nvnews.net/vbulletin/showthread.php?t=80690 This post also includes the nvidia bug report, which will include my xorg.conf and other pertinent system information if it is required.
You cannot really compare Beryl and xfwm4 compositor as Beryl/Compiz use OpenGL while xfwm4 uses Render to perform the compositing. If you want to compare the implementations, try xcompmgr or kcompmgr which both use Render. I'm using nVidia cards myself and let my system up and running for days and I'm not seeing that here. You may try xrestop to see if xfwm4 is leaking X memory (which I already checked several times) or try xcompmgr instead of xfwm4's embedded compositor. I're read that some people where experiencing slowdows on some systems, but xcompmgr was having the same rproblem so I would tend to think that the problem lies in nVidia proprietary driver. At least, you could try with the nv driver with Xorg 7.1 which use mmx to speed render in software. You won't be able to use full transparency, but the compositor is still usable with shadows. All in all, I don't think it's a problem with xfwm4.
Ok, I've made a very simple test. I open just 1 xterm and took the result of xrestop yesterday and got this result: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 0c00000 68 26 1 134 1945 9615K 48K 9664K 27019 xfwm4 Then, I hide the xterm (w/out resizing it so that the back buffer size of its window doesn't change) and launched a few applications I had to test (using OpenGL among other things), left them running all night, came back this morning, did a normal day of work, opening apps (including X resources hungry apps such as mozilla and thunderbird), moving, resizing windows, well, everything that is done is real life (actually, this is a real life test). Then at the end of the day, I closed all the windows but the xterm I initially started. From that xterm, I reran xrestop again, to see if there've been any leak in the window manager. Here follows the new results: res-base Wins GCs Fnts Pxms Misc Pxm mem Other Total PID Identifier 0c00000 68 26 1 134 1945 9615K 48K 9664K 27019 xfwm4 The results are (to my great surprise, I admit) totally similar, so I'm pretty confident that there is no leak in xfwm4 compositor. So if there is a leak somewhere, it could be in the hardware accelerated render implementation from nVidia maybe? Unfortunately, none but nVidia has access to this code. Or maybe in some other apps you are running? xrestop would surely tell you where an X resources leak could be.
I will try some things (xrestop for sure) and report back after I have time to test, which will be tonight or tomorrow.
Created attachment 892 xrestop after bootup This is a copy/paste of the xrestop output after I logged into XFCE. I started up Terminal, GAIM, and Mousepad.
Created attachment 893 xrestop after slowdown This is another snapshot of xrestop. The slowdown is now occuring. As you can see, xfwm4 has some inflated numbers. I was web surfing (firefox), checking email (thunderbird), playing WoW (with Wine), some development (bluefish and Anjuta), and Vmware. I believe VMware is the culprit as everything was working smoothly until I needed to startup VMware to run some virtual machines. Maybe xfwm4 and Vmware arn't getting along. I'll be honest, I haven't delt much with X debugging, so if there's something I can run just let me know. You might try downloading VMware and seeing if you get the same symptoms.
(In reply to comment #6) > This is another snapshot of xrestop. The slowdown is now occuring. As you can > see, xfwm4 has some inflated numbers. Hard to tell. The number of pixmaps and misc looks high, while the total memory is still fairly average. Are you sure that you have the exact same numbers of opened at the time? With a compositor, all windows are rendered to off-screen pixmaps, and the memory used by these pixmaps is seen as being alloted to the compositor process. Therefore, you must take the measure with the same number of mapped windows, with the same size, otherwise, the numbers will necessarily be different. > I was web surfing (firefox), checking email (thunderbird), playing WoW (with > Wine), some development (bluefish and Anjuta), and Vmware. > > I believe VMware is the culprit as everything was working smoothly until I > needed to startup VMware to run some virtual machines. Maybe xfwm4 and Vmware > arn't getting along. I'll be honest, I haven't delt much with X debugging, so > if there's something I can run just let me know. You might try downloading > VMware and seeing if you get the same symptoms. I'm using VMware player from time to time and never noticed that problem. can you open a terminal and type "xfwm4 --version" and post the result? TIA.
BTW, if you want to test the current SVN version of xfwm4, you can grab a snapshot either from http://www.foo-projects.org/~olivier/preview or from http://foo-projects.org/~elangelo/xfce-snapshots/ Compiling it is very straightforward as long as you have all the devel packages required to build from source.
Seems there are leaks in the compositor.
(In reply to comment #7) > > Hard to tell. The number of pixmaps and misc looks high, while the total memory > is still fairly average. Are you sure that you have the exact same numbers of > opened at the time? > I did have the same number of applications open. > > I'm using VMware player from time to time and never noticed that problem. can > you open a terminal and type "xfwm4 --version" and post the result? TIA. > This is xfwm4 version 4.3.99.2 (revision 23720) for Xfce 4.3.99.2 Released under the terms of the GNU General Public License. Compiled against GTK+-2.10.4, using GTK+-2.10.4. Build configuration and supported features: - Startup notification support: Yes - XSync support: Yes - Render support: Yes - Xrandr support: Yes - Embedded compositor: Yes - KDE systray proxy (deprecated): No I am using VMWare Workstation. It might be acting differently than the player is. I need the Workstation to create and run multiple VMs. Do you need me to run the latest SVN, or dp you already have the bug pinpointed?
(In reply to comment #10) > > Do you need me to run the latest SVN, or dp you already have the bug > pinpointed? > There is a huge leak, but not in the compositor. It leaks even w/out the compositor enabled. The problem lies in the MappingNotify callback, which is triggered by VMWare. That's why I could not see it, I did not run VMware during my tests. I'll commit a fix shortly.
That should be fixed with revision r24046. You can grab a snapshot of the sources here: http://www.foo-projects.org/~olivier/preview
Thanks! I will try the patch as soon as I can. I've updated the title so it is easier to understand/find in the future.
(In reply to comment #13) > I've updated the title so it is easier to understand/find in the future. Well, just for clarity, the problem is not VMware, it's just happen that VMware triggers a bug in xfwm4.
I've run revision 24047 for two days straight with a very wide spread of applications running on both my 32-bit and 64-bit systems. xrestop reports normal numbers now. I'll go ahead and resolve it as fixed. Thanks again, good work.
*** Bug 2687 has been marked as a duplicate of this bug. ***