Version: unspecified (using KDE 4.4.95) OS: Linux Subj. CPU usage in this time is 60-70%, thus, I can suggest, this isn't related with a capacity of my PC. After disabling Kwin compositing firefox works very smooth and fast, like a charm. At the same time, compositing not affect to slow and choppy scrolling in konqueror. Reproducible: Always
sounds like a Firefox bug, if it works with Konqueror, doesn't it? Although Firefox should not have any problems with it and we would have many complaints if there were a general problem with Firefox.
Hello. It is hard to notice, works it with konqueror or not, because scrolling in it works bad in anyway. First Firefox works well, but about half an hour later (sometimes it is 1 hour, sometimes — 10 minutes or does not happens at all) scrolling becomes slower and disabling of kwin effects helps. I watch it for a very long time, or even better to say — always. How you think, should I create a bug report on mozilla's bugzilla? Or they will send me back? Again and again...
On Thursday 29 July 2010 10:57:15 Alexander wrote: > How you think, should I create a bug report on mozilla's bugzilla? Or they > will send me back? Again and again... Yes I see the point, nevertheless we see that this seems to be related to the usage of Firefox. KWin will slow down as soon as there are too many repaints triggered. So an idea is to use the showPaint effect to verify if Firefox is constantly repainting. Just some ideas: check for Flash and Extensions.
a) what FF - 4.0beta has fundamentally different rendering/scrolling code b) 3.6 works like a charme here, nevertheless try disabling smooth scrolling ("about:config") c) Alexander has apparently a general* performance problem with pixmap->texture conversions and alphablended painting, no idea** why though *iirc, correct me if i'm wrong: cpu peaks when hovering sth. w/ or w/o compositing, slow konqueror rendering, slow FF rendering with compositing and all this across various driver iterations :-( **did i ask whether you've Option "AllowSHMPixmaps" "true" in your xorg.conf? in case: get rid of it... and ensure there's sth. like Option "RenderAccel" "true" Even better: try to remove (NOT delete, just rename it) your xorg.conf and restart X to have the driver configure itself.
(In reply to comment #3) > use the showPaint effect to verify if Firefox is constantly repainting. I already tried and it is unlikely that this is so. (In reply to comment #4) Yep, I have performance problem in general and seems that the reason is here — http://www.nvnews.net/vbulletin/showthread.php?t=115916 (partially or completely, I do not know) and the bug #234463 is not related to the compositing. But this current problem could happens only if Kwin compositing has been enabled. That is why I created a new bug report. Currently I use Firefox 3.6 and this is only one place in my system where the smooth scrolling is available (and kopete with kmail, but that does not count), and I would not want disable it :) This is all I have in /etc/X11/xorg.conf.d/20-nvidia.conf Section "Device" Identifier "Device0" Driver "nvidia" Option "RenderAccel" "true" //this string was added two three days ago, but nothing changed EndSection I already tried to hide the xorg.conf file and this gave nothing to me.
I tested another browsers (konqueror ana arora) and same problem appear in each of them. When compositing is disabled scrolling is very smooth. Also showPaint effect shows that firefox redraws only the view area, same as konqueror does. So, seems to problem in kwin. P.S. Yesterday I worked at the laptop with win 7 and just was shocked how smooth scrolling works here. When I've disabled compositing on my home desktop, scrolling became the same smooth.
During compilation of some application from source, all the interface becomes unusablel, scrolling is very and very choppy and slow, visual repaint of all widgets, tooltips, etc. Then kwin notice me about the very bad performance and disable all effects. After that the system becomes very fast again, scrolling becomes very smooth, all works very fine, but CPU usage is still 100% because of app compilation. The kwin compositing mode causes a much performance damage (although it should be opposite). In addition, it creates pressure on video card, that strongly affect the battery life. Of course, in theory, the compositing mode should shift the burden from the CPU to the GPU, but in practice it load booth devices, and when one of them (CPU in my case) is busy by other processes, kwin compositing becomes unable to work properly. And without compositing all looks ugly, especially plasma.
(In reply to comment #7) > During compilation of some application from source, all the interface becomes > unusablel, scrolling is very and very choppy and slow, visual repaint of all are you using indirect rendering?! > The kwin compositing mode causes a much performance damage (although it should > be opposite). false assumption. the GL_texture_from_pixmap conversion is a significant overhead. use the XRender backend where this is not required (and current nvidia drivers provide acceptable scaling performance) > affect the battery life. Of course, in theory, the compositing mode should > shift the burden from the CPU to the GPU, no. opengl is NOT the native X11 format, thus there must be a conversion, this causes an overhead which is balanced between the GPU and the CPU depending on your HW/Drivers and the kwin/X11 process depending on whether you use direct or indirect rendering. > but in practice it load booth devices, and when one of them (CPU in my case) is > busy by other processes, kwin compositing becomes unable to work properly. sounds A LOT like indirect rendering (or an indirecting effect like sharpen -stupid idea cause the nvidia driver can do that anyway w/o overhead- or blurring) regarding compilation & cpu load: "man:nice", in doubt: 'alias make="nice make"'
glxinfo | grep direct direct rendering: Yes XRender backend is not faster... perhaps it has its own weaknesses.
just a note: glxinfo does not tell you if KWin uses direct rendering. This can be enabled in KWin's advanced compositing settings. For NVIDIA blob it's the default. Please try again with 4.6 as there is some improvements in the vsync code. Please also report issues concerning Firefox 4 to Mozilla devs. We do not support or investigate issues in external beta applications.
I still have this problem. My system is : Kubuntu 10.10 Kde 4.6 Nvidia 425M with 1GB VRam (270.29 Beta driver) 6GB DDR3 RAM 1.73GHz i7 Quad Core (should be good enough) Tested with FF4, Opera 11 with smooth scrolling enabled for both. When Desktop Effects are disabled, scrolling is so smooth, however if they are enabled, very very laggy. I hope there will be a fix soon. I can give more information if needed.
Scrolling is still affected when compositing is enabled. Without compositing scrolling is smoother and faster. Tested in Firefox and Konqueror. Nvidia 9500GT with 1Gb memory Intel i7 3.2Ghz 2Gb DDR3 memory
From comment #2 "First Firefox works well, but about half an hour later (sometimes it is 1 hour, sometimes — 10 minutes or does not happens at all) scrolling becomes slower and disabling of kwin effects helps. I watch it for a very long time, or even better to say — always." Stupid question: could this be about power saving? (check the powermizer state in nvidia-settings) Just wonder because another bug reporter figured that powermizer would throttle his memory clock to 100Hz what's pretty low for large screen updates (though depending on the bandwidth which should be "only" 128bit on the 955GT & 425M) Scrolling implies large area updates because the system doesn't know that the content is only shifted what would allow for GREAT optimization in a bottom/up render stack :-(
errr - should have been "100MHz" (still low - but not /that/ low ;-)
> could this be about power saving? (check the powermizer state in > nvidia-settings) Performance mode: maximum performance. > "First Firefox works well, but about half an hour later (sometimes it > is 1 hour, > sometimes — 10 minutes or does not happens at all) scrolling becomes slower > and disabling of kwin effects helps. I watch it for a very long time, or > even better to say — always." I think that this problem was related to the Bug #234463 and now I avoid it by running next script: while true; do (nvidia-settings -a PixmapCache=0 && nvidia-settings -a PixmapCache=1) > /dev/null sleep 180 done But now I see a stable regression in scrolling when the compositing is enabled. It is not so noticeably in case if smooth scrolling is turned off.
As of 4.8.0 we have received many performance improvements. Because of that I consider this bug as fixed. In case you still experience slow scrolling with 4.8 I recommend to open a new bug report as the initial comment is from a rather outdated version.
*** Bug 271792 has been marked as a duplicate of this bug. ***