Just upgraded XFCE (in gentoo) from 4.4.3 to 4.6.0 and the compositing is noticeably slower now (namely: moving windows is not as smooth as it used to be in 4.4.3, when compositing is enabled). Actually, in 4.4.3 I couldn't tell the difference in speed between the cases with compositing on/off. Both were smooth. Now it's easily noticeable whether the compositing is on or off. I have also tested it in Ubuntu jaunty (which has 4.6.0 now) and the experience is virtually the same there. Actually I have both Ubuntu and Gentoo installed, and noticed the difference in speed between the two even before the upgrade (slower in ubuntu with 4.6.0, faster in gentoo with 4.4.3). HW: Core2Duo E4600 @ 3.0GHz, 2GB RAM, Nvidia 8800GT
gentoo: X.Org server 1.5.3, NVidia driver 180.37 ubuntu: X.Org server 1.6.0, NVidia driver 180.35
I am not seeing that here, can you try with either "nv" or "nouveau" instead?
Also please note the compositor now bufferezise the repaint and redraws only every 20ms so you may look slower (whereas it is actually faster)
(In reply to comment #3) > Also please note the compositor now bufferezise the repaint and redraws only > every 20ms so you may look slower (whereas it is actually faster) I don't quite understand what you wanted to say here, I have no idea how it could look slower and be faster at the same time :-) I've tested it with the nv driver, and also tried it on a notebook with ATI Mobility Radeon™ X1400 and the feeling is virtually the same with all the distros/machines/drivers. Smooth without compositing, somehow "film-like" (with well defined "frames") when compositing is on. It probably really is the redrawing only every 20ms that I'm writing about (actually in my case it is more than 20ms - I would say it's about 50ms). Probably there is a good reason for it, but for me, it's a regression. It just used to be so much better in 4.4.3. As I've said, totally smooth, I couldn't tell (from the speed) whether compositing was on or off (actually I was rather surprised to find that it was that smooth). Anyway, I have stopped using the compositing now, since this "20ms framerate" or how to call it is uncomfortable for me, e.g. in the XFCE menu. Without compositing, when I move mouse accross the menu, I see that all the items get subsequently highlighted, as the mouse moves over them (..if I don't move the mouse really really fast..). But with compositing on, only some of the items gets selected as the mouse moves (and this happens even with rather moderate speed of mouse). So it is noticeably harder (at least for me) to select items from the menu with compositing on. I have to move the mouse somehow slower than with compositing off. Is there a way how to disable the 20ms framerate and go back to the previous state? Runtime option/compile-time option/patch. PS: Some other people's comments, probably about the same thing: http://forum.xfce.org/index.php?topic=4685.0
(In reply to comment #3) > Also please note the compositor now bufferezise the repaint and redraws only > every 20ms so you may look slower (whereas it is actually faster) I probably know now what you meant; the reduced framerate probably increases speed, at least on machines that couldn't compute higher number of frames. Actually the speed is ok. It's the choppiness I'd like to complain about. A better title for the bug would be "Compositing is more choppy in 4.6.0 than it was in 4.4.3". As I have written in the previous post, this has consequences for usability too.
(In reply to comment #5) > (In reply to comment #3) > > Also please note the compositor now bufferezise the repaint and redraws only > > every 20ms so you may look slower (whereas it is actually faster) > > I probably know now what you meant; the reduced framerate probably increases > speed, at least on machines that couldn't compute higher number of frames. > Actually the speed is ok. It's the choppiness I'd like to complain about. A > better title for the bug would be "Compositing is more choppy in 4.6.0 than it > was in 4.4.3". > > As I have written in the previous post, this has consequences for usability > too. Agreed.
(In reply to comment #6) > (In reply to comment #5) > > As I have written in the previous post, this has consequences for usability > > too. > > Agreed. But reverting to the previous implementation *really* feels much slower here. So maybe the solution would be a compromise, keep the timeout based repaint but reduce the value of the timeout.