After waiting 4 weeks for xfce 4.6 to finally and completely arrive in debian unstable I have to file this bugreport for its PRETTY SLOW! To be precisely: running latest xfce packages from debian unstable, I open a terminal window and execute top. Then I open another and move that window over my desktop and Xorg usage goes up to 100% and the movement judders like hell! Same goes for simple scrolling through the virtual desktops, there is a latency of > 2 secs while I wait for the next desktop to show up. For all the shortanswering ppl: Its prolly _not_ a Xorg report because it doesnt happen on other Windowmanagers, and its neither a requirements issue because a 2,4 ghz P4 should still be more than enough for a window manager which preens itself for being "fast and lightweight". Whilst waiting for the packages gettin into unstable I had a pretty fast xfce4.6 as long as the xfce4-session packages hasnt been build and installed yet, therefore I assign this bug to xfce4-session package. I'd love to provide more info on that issue, just ask what you need to know!
For future reference: bugzilla is not a place for you to rant. If you need a place to rant, start a blog or something. The total useful bug-report-related content here is about 8 words long. If anything, this is a WM problem, or an Xorg problem (sorry, regardless of what you may think, it might be). No way this has anything to do with the session manager.
Do you use Terminal (aka xfce4-terminal in Debian)? Terminal is broken as it uses ARGB windows by default wich is not well supported by many X drivers and this is causing major slowdowns. Try disabling ARGB window (e.g. create a script in /etc/profile.d/ to do "export XLIB_SKIP_ARGB_VISUALS=1") or even compositing all together. Or get rid of Terminal. Anyway, I am lowering the criticity of your bug report to Low/Minor because you being upset does not qialify as a major issue in xfce.
No, I use urxvt as a terminal, not the xfce4-terminal. "export XLIB_SKIP_ARGB_VISUALS=1" didnt change anything and compositing is disabled, just checked again. It's not just the terminal windows, moving every window, even the Pidgin buddylist eats up the CPU!
Ok, then did you check what process eats cpu?
The process Xorg goes up to 100%, as I mentioned before.
FYI, Xfwm4 uses XConfigureWindow() to move/resize windows, which is the standard API to move and resize windows, nothing particularly fancy there so I don't see why/how this could be an issue with the window manager. You also complain that xfce 4.6 is slow, but did you try xfce 4.4 on the same hardware and exact same installation? That code hasn't changed much since xfwm4 4.0 so IO hardly see how a regression could have occurred there. Can you also give some details on the video card you use and the driver? I have a old P4 and xfce 4.6 works just fine on that hardware. There is one possiblity, that with a very card with very little pixmap memory,, the X server may have to transfer pixmaps from and to the main memory with is very slow. There are more tests you can do, e.g. from with xfce, try replacing the window manager with another one (e.g. "metacity --replace" or "openbox --replace") or even try quitting some components that may be using a lot of pixmap memory, starting with xfdesktop.
I tried xfce 4.4, runs perfectly smooth. My video Card is a Nvidia Geforce4 Ti 4200 with 64 MB or 128MB ram (not 100% sure about it, cause I got 3 such cards with different RAM and I dont know which one is inside this pc right now) Driver is the latest legacy from nvidia.com. I also tried metacity, no improvements. xfdesktop4 is respawning too fast to be able to test anything.
(In reply to comment #7) > I tried xfce 4.4, runs perfectly smooth. > > My video Card is a Nvidia Geforce4 Ti 4200 with 64 MB or 128MB ram (not 100% > sure about it, cause I got 3 such cards with different RAM and I dont know > which one is inside this pc right now) Driver is the latest legacy from > nvidia.com. So I now strongly suspect this might be related somehow to this commit r27940: http://svn.xfce.org/index.cgi/xfce/xfdesktop/trunk/src/xfce-desktop.c?r1=27940&r2=27939&pathrev=27940 Which was discussed on the ML here: http://foo-projects.org/pipermail/xfce4-dev/2008-September/025122.html and here: http://foo-projects.org/pipermail/xfce4-dev/2008-October/025155.html > I also tried metacity, no improvements. Which proves this is not an xfwm4 bug > xfdesktop4 is respawning too fast to be able to test anything. Yes, you need to use the xfce4-session-setting dialog to remove it. In doubt, try renaming the binary temprarily and restart the session entirely. In the desktop behave normally without xfdesktop, then you'll now I was right suspecting double buffering xfdesktop (as explained in the thread, back in time).
Ok, I think you were right suspecting xfdesktop as the root of evil. After renaming it and restarting my xfce everything was back to normal. So does this now mean, for I cant disable double buffering (or can I?) my Geforce 4 is too "weak" for the "fast and lightweight" xfce?
Brian, I guess I can reassign this bug to you. My guess is that it's commit 27940, ie disabling double buffering.
(In reply to comment #9) > [...] > So does this now mean, for I cant disable double buffering (or can I?) my > Geforce 4 is too "weak" for the "fast and lightweight" xfce? Just you start some trolling, have you tried with the open source driver?
(In reply to comment #10) > Brian, I guess I can reassign this bug to you. My guess is that it's commit > 27940, ie disabling double buffering. ^^^^^^^^^ I mean re-enabling of course!
Can't really disable double buffering... rubber banding looks like shit without it.
(In reply to comment #13) > Can't really disable double buffering... rubber banding looks like shit without > it. Well, I wouldn't be surprise if this bug would be specific to the NVidia proprietary driver anyway (never heard of this with neither "nv" nor "nouveau" drivers), so I am not sure it's worth it, but better check that first. (In reply to comment #9) > [...] my Geforce 4 is too "weak" for the "fast and lightweight" xfce? So please check if the bug is present with one of the free drivers, either "nv" or "nouveau" (or even "vesa", which is totally unaccelerated) and report.
(In reply to comment #14) > (In reply to comment #9) > > [...] my Geforce 4 is too "weak" for the "fast and lightweight" xfce? > > So please check if the bug is present with one of the free drivers, either "nv" > or "nouveau" (or even "vesa", which is totally unaccelerated) and report. That comment is for the reporter of the bug, of course...
Well it really seems that the problem occurs with the nvidia proprietary driver only. Switching to nv changed the window movement back to normal. My question now: Should I File a bug report or something to nvidia or are you gonna do that? I suggest you, because this behaviour only happens with xfce and not with any other window manager and I think the optimization has probably to be done on both sides or at least definitely on yours. Thank you all so far for the help, I can live with the nv driver until the next nvidia driver release. The nouveau driver is way to alpha to use, for now.
(In reply to comment #16) > Well it really seems that the problem occurs with the nvidia proprietary driver > only. > > Switching to nv changed the window movement back to normal. > > My question now: Should I File a bug report or something to nvidia or are you > gonna do that? I suggest you, because this behaviour only happens with xfce and > not with any other window manager and I think the optimization has probably to > be done on both sides or at least definitely on yours. Why should we (as Xfce developpers) bother opening a bug with NVidia, you are their customer, not us. Additionaly, it's been demonstrated that this is not a window manager issue. You are confusing desktops and window managers. BTW, this is not a bug or a matter of optimization, it's a matter of resource management in the NVidia driver that probably reserves too much of the so little on-board memory available on your old video card for textures and not enough for pixmaps. If you have not yet done it, I'd suggest you check for a possible option in the NVidia driver, who knows... > Thank you all so far for the help, I can live with the nv driver until the next > nvidia driver release. The nouveau driver is way to alpha to use, for now. I doubt you'll get any update of the legacy driver, as I doubt that NVidia would be interested in updating that driver for such an old, deprecated hardware (NVidia writes a driver to sell its hardware, remember). But feel free to bug NVidia about this and prove me wrong.
Looks like the recommendations here: http://www.nvnews.net/vbulletin/showthread.php?t=118088 made it. Now I'm back to 50-60% CPU usage when I move a window. This report can be marked as solved.
not us...
I have also been seeing this issue. Using GeForce2 MX/MX 400 and proprietary driver. I can also confirm that this is due to changes from xfdesktop-4.4 to 4.6.1 I have updated all xfce4 to 4.6.1 and reverting just the desktop pkg solves the speed problem. The link #18 is irrelevant since the driver version refered to there does not work on these older cards. I the same behaviour on 96.43.09, *10 and *11 drivers. from #17 >> I doubt you'll get any update of the legacy driver, as I doubt that NVidia would be interested in updating that driver for such an old, deprecated hardware (NVidia writes a driver to sell its hardware, remember). >> Well I have seen two updates to that driver since I hit this issue with xfdesktop. NV do have a very positive approach to maintaining support for older hardware. This is brilliant because I dont want super wizz gaming card with a turbo fan on it to run my desktop machine. This card had passive heat sink and is SILENT. For me that's a big plus, not "deprecated". NV have always been strong in supporting linux, both these facts mean I only buy kit with NV graphic chips. So they do support legacy hardware and it makes commercial sense. They get my vote. This may be a clue to something being wrong, I tried running glxgears on 4.6.1 : bash-4.0#glxgears Error: couldn't get an RGB, Double-buffered visual Is xfce assuming it's getting double buffering when in fact it is not?
(In reply to comment #20) > bash-4.0#glxgears > Error: couldn't get an RGB, Double-buffered visual > > Is xfce assuming it's getting double buffering when in fact it is not? This is unrelated. Gtk does double-buffering in software, client-side (sorta). It doesn't depend on any driver or X server support. (Interestingly, I have no problem using the nvidia proprietary driver with xfdesktop 4.6 and composite enabled, but I suppose that could be because my new laptop has a relatively new GPU and plenty of VRAM.) At any rate, unless there's any new evidence to suggest that the issue isn't a resource management problem in the nvidia proprietary driver, there's nothing new to do with this bug.
OK, so what's the workaround on this? Am I going to run into other problems if I block >xfdesktop-4.4 or should I try hacking 4.6.1 and reinserting the double buffer lines that are mentioned in the commit above> thx
(In reply to comment #22) > Am I going to run into other problems if I block >xfdesktop-4.4 or should I try > hacking 4.6.1 and reinserting the double buffer lines that are mentioned in the > commit above> Either way should be ok, but xfdesktop 4.4 will pull in some other dependencies that 4.6 doesn't require, and configuring xfdesktop will mean using a different tool (xfce-mcs-manager from 4.4). On a side note, does anyone have Nautilus installed? You could try to run it (after quitting xfdesktop), and allow it to draw the desktop window. See if you have the same problem there. If not, I'd be interested in learning out how Nautilus does its drawing such that it's flicker-free and doesn't cause problems on memory-constrained cards.
I could install N to test but I don't understand what you mean by "quitting xfdesktop" . In what context should I run N ?
"xfdesktop --quit". I don't understand what you mean by "context". Just run it.
OK , I did not realise xfdesktop was non essential to running xfce4, that's what was confusing me. Now I have install nautilus and reinstalled xfdesktop 4.6.1 If I quit xfd I get the grey patterned desktop background. On running nautilus it pops up a few icons and adds an bg image. Although I can't flip desktops with the mouse wheel as I do with xfd, it works fast and normally going from one desktop to another, no visual defects.
*** Bug 5786 has been marked as a duplicate of this bug. ***