Summary: | Scrolling webpages in tabs is slow with oxygen | ||
---|---|---|---|
Product: | [Plasma] Oxygen | Reporter: | Daniel Eklöf <daniel> |
Component: | style | Assignee: | Hugo Pereira Da Costa <hugo.pereira.da.costa> |
Status: | RESOLVED UPSTREAM | ||
Severity: | normal | CC: | hugo.pereira.da.costa |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | Compiled Sources | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Daniel Eklöf
2010-12-30 21:27:08 UTC
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? |