Version: unspecified (using KDE 4.5.90) OS: Linux Using either rekonq or konqueror, scrolling webpages is really slow when: a) tabs are used to display the web page (always true in rekonq, true in konqueror when more than one tab is opened) b) "native" is used as qt graphics system c) anti-aliasing is turned OFF ( d) the proprietary nvidia driver is used? ) Switching to the "raster" engine, or enabling anti-aliasing improves the situation a lot, although I'm not convinced it completely fixes the problem. Switching to another style ("Plastique" for example) fixes the problem completely, making me think there's some interaction problem between oxygen and the rest of the rendering stack, possibly related to font rendering. My guess is oxygen does something with tabs that causes HW acceleration to be disabled and fallback on SW rendering. Which I guess might mean this only applies to nvidia. Reproducible: Always Steps to Reproduce: Load a page that can be scrolled in konqueror. Make sure it's the only page (i.e. no tabs). Scrolling should be fast. Open a second tab (no need to load a second page, just switching to tabbed browsing is enough). Scrolling on the first page is now *a lot* slower. Since rekonq always uses tabs, even when there's only a single page loaded, scrolling is always slow (but! note that in versions up to, and including 0.6.1, rekonq programmatically switched to the raster engine, which more or less hides the problem. The latest git version does not do this; i.e. it uses the default engine, "native" in my case) xorg-server 1.9.3 KDE 4.6 RC1 nvidia proprietary driver 260.19.29 Some pages are slower than others, obviously, but google search results definitely belong to the slower ones.
Some gradients are indeed software rendered by Qt due to a bug in proprietary Nvidia drivers, that prevents them to be hardware accelerated. Such gradients are indeed used all over the place in oxygen, unlike other theme, such as plastique. They are used notably in tabs. So that might indeed cause a problem. On the other hand I cant reproduce here, with kde 4.5.4, Oxygen from trunk, and Nvidia 260.19.29 and Qt 4.7.1. In any case, there is not much oxygen can do about it. Will close as upstream (either Qt needing finer tuning between Software/Hardware acceleration; or rather: nvidia fix their damn drivers - pardon my french :)) Question though: how does scrolling in dolphin behave, with/without tabs ?
(In reply to comment #1) > Some gradients are indeed software rendered by Qt due to a bug in proprietary > Nvidia drivers, that prevents them to be hardware accelerated. Such gradients > are indeed used all over the place in oxygen, unlike other theme, such as > plastique. They are used notably in tabs. So that might indeed cause a problem. That may very well be what's going on. For the record though, I'm currently using QtCurve with the "ozone" preset. It also uses gradients all over the place, including tabs. That doesn't necessarily mean anything, but I thought it might be worth mentioning. > On the other hand I cant reproduce here, with kde 4.5.4, Oxygen from trunk, and > Nvidia 260.19.29 and Qt 4.7.1. I *think* there was a noticable drop in performance when I switched to xorg-server 1.9.0. Maybe related to that? Btw, I'm also on Qt 4.7.1. > Question though: how does scrolling in dolphin behave, with/without tabs ? Slow, both with and without tabs. But then that's true regardless of widget style. And perhaps most importantly, I don't see any _difference_ in performance with and without tabs.
(In reply to comment #2) > I *think* there was a noticable drop in performance when I switched to > xorg-server 1.9.0. Maybe related to that? Btw, I'm also on Qt 4.7.1. To clarify: performance was better in xorg-server 1.8.x. In 1.9.0 something happened that caused non-anti-aliased fonts to not be hw accelerated. See http://www.nvnews.net/vbulletin/showthread.php?t=154563. Most of the issues related to that has now been fixed. Not sure if the current oxygen-problem is related, but I have to say, it does look very similar, seeing that enabling anti-aliasing "fixes" the problem (btw, did you remember to disable anti-aliasing when you tried to reproduce?)
Now it's coming back to me again... the issue with 1.9.0 was sort the opposite from this... anti-aliased text was slow, whereas in this case, it's non-anti-aliased text that is slow.
at comment #3: no I did not disable anti-aliasing. Will try again :)
ok. When disabling antialiasing, I can reproduce the issue. Now, again (and unfortunately) I don't know of anything oxygen can do to fix. Code has no control on anti-aliasing/software vs hardware acceleration. On the comparison with QtCurve, I don't know what to make of it. Both codes have nothing in common (and both makes only perfectly valid Qt painting calls). I'm not saying that Oxygen could not be optimized more, but I don't know where to look. (note that there have been quite some effort at optimizing already, notably between 4.5 and 4.6 ...)
(In reply to comment #6) > ok. When disabling antialiasing, I can reproduce the issue. > Now, again (and unfortunately) I don't know of anything oxygen can do to fix. > Code has no control on anti-aliasing/software vs hardware acceleration. Ok, cool. > On the comparison with QtCurve, I don't know what to make of it. Both codes > have nothing in common (and both makes only perfectly valid Qt painting calls). > I'm not saying that Oxygen could not be optimized more, but I don't know where > to look. Perhaps using a profiler, one could find out what exactly is falling back on sw, and based on the call trace find the problem? I'm no stranger to debuggers and profilers, but I'm afraid I _am_ a stranger to the KDE code base, oxygen included :) I've also not done any graphics profiling before... > (note that there have been quite some effort at optimizing already, notably > between 4.5 and 4.6 ...) I assume all of those are already in RC1? So we know that none of those optimizations fixes the problem, right?