Bug 245740 - Scrolling in kde 4.5 is laggy
Summary: Scrolling in kde 4.5 is laggy
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 16.12.2
Platform: Unlisted Binaries Linux
: NOR normal
Target Milestone: ---
Assignee: Peter Penz
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-07-25 14:27 UTC by Simonas
Modified: 2011-12-12 18:13 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.8.0


Attachments
Scrolling in "/usr/lib" (660.51 KB, application/octet-stream)
2010-07-29 11:26 UTC, Alexander
Details
script to retrieve, configure and compile oxygen from svn trunk (6.03 KB, application/x-perl)
2010-09-02 18:24 UTC, Hugo Pereira Da Costa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Simonas 2010-07-25 14:27:28 UTC
Version:           unspecified (using KDE 4.4.92) 
OS:                Linux

This doesnt happen in kde 4.4. Im using latest xorg, latest nvidia driver on my geforce 9500gt. My pc is brand new: athlon II x2 250 3.0ghz, 2gb ram. My qt installation hasnt been changed when i upgraded

Reproducible: Always

Steps to Reproduce:
Open up dolphin, open folder which has many files, maximize dolphin window, and try to scroll with scrollbar. you will see that scrolling is laggy and choppy. 

Actual Results:  
The scrolling is laggy. 

Expected Results:  
The scrolling shoud be smooth as in kde 4.4
Comment 1 Christoph Feck 2010-07-26 15:07:27 UTC
Probably due to changes in icon loading. It depends on the file types and icons showing. For example, folder icons seem slower (no folder previews enabled).
Comment 2 Simonas 2010-07-26 20:51:25 UTC
(In reply to comment #1)
> Probably due to changes in icon loading. It depends on the file types and icons
> showing. For example, folder icons seem slower (no folder previews enabled).

no no no no. i can reproduce that in konqueror and all other kde applications.
Comment 3 Alexander 2010-07-29 11:26:26 UTC
Created attachment 49625 [details]
Scrolling in "/usr/lib"

Can confirm it in KDE 4.5 RC3. In 4.4.* it happens sometimes, that is sometimes scrolling works fine (see bug #234463), but in 4.5 scrolling in Dolphin (in Konqueror too) always slow and affected.
Comment 4 Peter Penz 2010-07-29 12:15:43 UTC
@Alexander: I could not open your attachment, but one question: /usr/lib is maybe not the best directory to measure the pure scrolling speed, as in /usr/lib for each item the MIME type gets determined asynchronously the most expensive way by looking into the content and this can take a while (the speed has been improved in this case in comparison to 4.4 btw).

A good example to test the pure scrolling speed would be e. g. a huge image directory without (!) enabled previews (-> mime type is known already by the file name). Also it would be important to know which view mode you are using (icons, details, columns). Thanks!
Comment 5 Alexander 2010-07-29 13:41:44 UTC
Attachment is a Sysprof file — http://www.daimi.au.dk/~sandmann/sysprof/

> but one question: /usr/lib is maybe not the best directory to measure the pure
> scrolling speed, as in /usr/lib for each item the MIME type gets determined
> asynchronously the most expensive way by looking into the content and this can
> take a while (the speed has been improved in this case in comparison to 4.4
> btw).
All of this is true but this related only to the directory opening time.

> A good example to test the pure scrolling speed would be e. g. a huge image
> directory without (!) enabled previews
Scrolling works slow if I'll open /usr/lib and await half an hour before scrolling it or if I will scroll it these half an hour without stop. Also I have directory with music, it contains only folders (117 items) and scrolling works very slow. The same slow as in the folder that contain only pictures without preview.

Interesting the moment that the folder with pictures and with enabled preview scrolls absolutely smoothly. After disabling preview it's again becomes slow and affected.

The details view has the same problems but it is not so hard.

Another moment — than the icons size is bigger then scrolling is faster and smoother. By default I have 48px for all views (and the same size from preview mode). So, icons view scrolls absolutely smooth with the 176px icons size and with 96px in the details view mode.

Another thing I want to notice — the "mouseover" event should be blocked during scrolling. It's because if the "information" panel is enabled — it tries to update information when you hovering items during scrolling.

Also the "show in groups" view has additional performance lags.

In KDE 4.4.* I've had very smoother scrolling, even in the /usr/lib folder.
Comment 6 Alexander 2010-07-29 13:48:42 UTC
Columns view works smooth and fast, with all icons sizes and in all folders.
Comment 7 Alexander 2010-07-30 16:07:27 UTC
(In reply to comment #6)
> Columns view works smooth and fast, with all icons sizes and in all folders.
I also think this is due to the grid size, like in the case with icons size. So, perhaps there is some rendering regressions, etc.
Comment 8 Peter Penz 2010-08-08 11:33:20 UTC
Alexander, would it be possible that you temporary rename your ~/.kde (or ~/.kde4) directory? This is just a wild guess, but maybe Christoph is really right in comment #1; at least the fact that the scrolling is OK with enabled previews might support this guess and probably the icon loader code gets messed up with some old data in the .kde directory (should of course not be, but if temporary renaming .kde helps, we have at least an indication that it is related to the content in .kde). Thanks!
Comment 9 Alexander 2010-08-08 13:13:35 UTC
(In reply to comment #8)
Hi. I already tried that, but nothing.
Comment 10 Peter Penz 2010-08-08 14:30:08 UTC
Hm, another wild guess: Does it change something if you start Dolphin with a different paint device engine? E. g.
dolphin -graphicssystem raster
dolphin -graphicssystem x11
dolphin -graphicssystem opengl2
dolphin -graphicssystem opengl
Comment 11 Alexander 2010-08-08 15:43:45 UTC
Raster is fastest of them, it works much faster than dolphin works by default, even selecting a bunch of files works faster with it. Opengl, opengl2 is incredible slow. X11 — Unable to load graphicssystem "x11".
Comment 12 Peter Penz 2010-08-08 22:01:22 UTC
In this case it is quite sure, that it is an issue of your graphics driver in combination with Qt :-( "Raster" lets all graphic operations run on your CPU, so if this is faster than with your graphics card, then there seems to be a specific bottleneck in your used driver, that gets a problem in combination with scrolling. If you agree, I'd like to close this issue for Dolphin, as there is nothing that I can do against it. I'm wondering: Don't you have any hangs when e. g. using Plasma?
Comment 13 Alexander 2010-08-09 08:23:32 UTC
No, any hangs. But I have this bug #234463 and strange that in KDE 4.4.5 I have not see this regression in dolphin, with the same nvidia driver and kernel. And if this is a driver issue, why scrolling works just fine with enabled preview of video/images files and worse with disabled? But still, the most important thing is that in KDE 4.4.5 scrolling of the same folders work fine.
Comment 14 Simonas 2010-08-09 15:31:27 UTC
(In reply to comment #13)
> No, any hangs. But I have this bug #234463 and strange that in KDE 4.4.5 I have
> not see this regression in dolphin, with the same nvidia driver and kernel. And
> if this is a driver issue, why scrolling works just fine with enabled preview
> of video/images files and worse with disabled? But still, the most important
> thing is that in KDE 4.4.5 scrolling of the same folders work fine.

Thats exactly what i want to say. I also havent modified xorg-server, nvidia driver or qt version, but in 4.4 scrolling is just fine. By the way this does happen only in dolphin now. In konqueror and gwenview laggy scrolling is resolved in rc3. But the dolphin remains to be slow. When i make icons very big, the scrolling is smooth, but when i make them smaller (this means that more icons are displayed because smaller icons means more icons on same space) the scrolling is laggy. So i guess when dolphin displays lots of files, scrolling is choppy.
Comment 15 Alexander 2010-08-29 07:33:33 UTC
(In reply to comment #14)
Maybe you should have been change the bug status back from "needsinfo" to "unconfirmed".

P.S. For me konqueror also has all the same problems with scrolling as dolphin.
Comment 16 Peter Penz 2010-08-29 09:57:10 UTC
Hm, it still would be great if you could provide further infos, as this seems not to be a general issue (otherwise we'd have a lot of duplicates here). It can of course be, that a minor change in 4.5 triggers a bottleneck now in your unchanged graphics driver (at least comment #11 indicates this). Does it help if you:
- Change the style (from Oxygen to e.g. Plastique)?
- Turn off desktop effects?
- Change the font?

@Simonas: In comment #14 you say you cannot reproduce it in Konqueror, in comment #2 you say it is equally slow. As Konqueror uses the Dolphin KPart for scrolling, at least in theory the speed should be equal. Could you please check again and assure that the window sizes etc. are absolutely equal? Also please turn off all panels in Dolphin that are not shown in Konqueror to assure an equal test environment. Thanks!
Comment 17 Alexander 2010-08-29 10:24:41 UTC
(In reply to comment #16)
> Does it help if you:
> - Change the style (from Oxygen to e.g. Plastique)?
> - Turn off desktop effects?
> - Change the font?
No, it doesn't.

In KDE 4.4 dolphin used "raster" graphics system by default? If not (and even if yes, in 4.4 scrolling worked faster that in 4.5 with the raster graphics) — this is a regression somewhere in kdelibs or in dolphin. Because all other system components were the same.
Comment 18 Peter Penz 2010-08-29 11:52:41 UTC
> In KDE 4.4 dolphin used "raster" graphics system by default?

Dolphin does not chose a specific graphics system, this is decided by Qt AFAIK and should not have been changed.

Can you reproduce the issue in the file-open dialog too (assuming that you resize it to a similar size like dolphin or konqueror)?
Comment 19 Alexander 2010-08-29 13:52:41 UTC
(In reply to comment #18)
> Can you reproduce the issue in the file-open dialog too
Ok, I have created a folder with 500 sub-folders and have launched kwrite with its "open file" dialog. All windows has been maximized (19").

Last result:
1. Scrolling in folder with 500 sub-folders works bad but a little better than in dolphin.
2. Scrolling in folder that contains only pictures in the open file dialog works fast in both cases, with enabled and disabled preview.
3. Scrolling in /usr/lib works fine.

--------------------------------------

But first I have done differently. I had launched kwrite and gwenview with their open file dialogs and was made them identical by appearance and settings. In kwrite dialog scrolling in folder with pictures worked same bad like in dolphin, but in gwenview dialog it worked just fine. I had opened the same folder in dolphin and scrolling worked fine and here too! But after restart of dolphin all returned back.

Now I again launched gwenview, opened pictures folder in its open file dialog and scrolling works bad again (with disabled preview, with enabled — fine, just like in dolphin). Closed it, opened kwrite, same actions ... scrolling works fine (but both, with enabled and disabled preview), but in /usr/lib — bad.

Strange things...
Comment 20 Daniel Buus 2010-08-31 19:04:40 UTC
Have you tried disabling direct rendering in desktop effects?

After my upgrade to 4.5 using ubuntu backports, I had serious issues with lagging, and one of the things that was really horrible was this scrolling experience of yours. Add to that that when using the exposé clone, all window preview turned into white squares and animations were horribly choppy.

I can't say for sure if among the 100+ packages that were pulled from backports when I upgraded, a couple weren't for X or something else (kernel still the same, though), but this happened after the KDE upgrade anyway. Disabling direct rendering fixed it for me.  Yeah, I know, weird :) Maybe it's got to do with the deal about blurring being enabled again as stated in the release notes?

Anyway, I also "feel", though that's hard to debug, that scrolling has gotten slower since KDE 4.4.5 when having many items listed in Dolphin (I'm currently organizing a bunch of backups, so I've been at it for a couple of weeks now).

Anyway, just an idea :)
Comment 21 S. Christian Collins 2010-09-01 02:28:14 UTC
All of my Dolphin sluggishness has gone away after switching the widget style to QtCurve.

** My System **
Motherboard: MSI K9N SLI Platinum (nForce 570 SLI chipset)
CPU: AMD Athlon(tm) 64 Processor 4000+ (2.6 GHz)
RAM: 2GB DDR2
Video: Dell NVIDIA GeForce 7800 GTX w/ 256 MB RAM (PCI Express)
OS: Kubuntu 10.04 i386 w/ KDE SC 4.5.0 from Kubuntu PPA
Linux Kernel: 2.6.32-24-lowlatency
NVIDIA driver: 256.52
Screen Resolution: 1280 x 960
X.org: 7.5
Qt: 4.7.0 beta2
Comment 22 Simonas 2010-09-01 08:51:00 UTC
Hi,
Ive tried to switch to qtcurve too and laggy scrolling is gone to me! It looks like its oxygen style issue. So you can close bug now, or change the product code to oxygen style and send that bug to hugo pereira.
Thank you for your care.
Comment 23 Peter Penz 2010-09-01 11:35:28 UTC
@Simonas: Thanks for checking, I've reassigned this to Oxygen now.
Comment 24 Hugo Pereira Da Costa 2010-09-01 19:45:26 UTC
Hi,
though I did not *yet* read all the posts in details, yes it is related to a change in oxygen between 4.4 and 4.5 (also it is _also_ related to the graphics card, and the paint engine).
The change in oxygen is that the frame "inner" shadow now overlaps with the mainview. 

So that it gets updated every time the viewport is, which can be rather slow depending on the engine. 

Actually, skulpture uses the same mechanism as oxygen to render frame shadows. Can someone tell me if the same slowlyness is visible with skulpture ? 
(and I think bespin also uses the same mechanism).

On my side, I will see if these new shadows triggers some unnecessary repaints in the code. If it doesn't, then there is not much that can be done on the oxygen side. (the kde4.4 shadows where ugly, because of not overlapping with the view: there was an extra grey pixel between the frame and the view, so that I will not revert the change).

I hope it makes some sort of sense,

Hugo
Comment 25 Hugo Pereira Da Costa 2010-09-02 03:22:57 UTC
SVN commit 1170766 by hpereiradacosta:

Reduced size of the frame shadow widgets, notably to avoid overlaps with other widget (e.g. scrollbars), and thus 
reduce the number of repaints.

CCBUG: 245740


 M  +5 -4      oxygenframeshadow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1170766
Comment 26 Hugo Pereira Da Costa 2010-09-02 03:24:46 UTC
SVN commit 1170767 by hpereiradacosta:

backport r1170765
Reduced size of the frame shadow widgets, notably to avoid overlaps with other widget (e.g. scrollbars), and thus
reduce the number of repaints.
CCBUG: 245740


 M  +5 -4      oxygenframeshadow.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1170767
Comment 27 Hugo Pereira Da Costa 2010-09-02 03:28:59 UTC
Could someone running with trunk (or oxygen from trunk) double check whether commits 1170766/1170767 do improve things ? 
(it should, at least a bit, but since I can't reproduce things on my intel GC, I can't really tell).
Comment 28 Christoph Feck 2010-09-02 03:36:45 UTC
For me, scrolling in Dolphin is slow because of the type of files/icons it displays. For example, when I go to /usr/lib folder, which is quite crowded, I get fast scrolling speed at when I am at the ".la" files, very slow scrolling speed when I am at the files ".so" files (which are softlinks), and a somewhat medium scrolling speed when I am at the directories at the top.

I am still convinced that it depends on icon loading or file type detection or something else related to it.

(and no, I don't use Oxygen, and the speed feels the same with Plastique as well as with Skulpture.)
Comment 29 Hugo Pereira Da Costa 2010-09-02 03:56:28 UTC
SVN commit 1170776 by hpereiradacosta:

backport r1170775
More reduction of frame shadow widget's size.
CCBUG: 245740


 M  +1 -1      oxygenframeshadow.cpp  
 M  +22 -10    oxygenframeshadow.h  


WebSVN link: http://websvn.kde.org/?view=rev&revision=1170776
Comment 30 Hugo Pereira Da Costa 2010-09-02 04:38:19 UTC
@Christoph (comment #28)
I have an explanation for your observation which is quite different from your conclusion.
I added a printout to all "Oxygen::FrameShadow::paintEvent".
And looked at it whether I select icon view or list view, and scroll.
Turns out: 
there is no paint event triggered when scrolling a list view,
there are many paint event triggered when scrolling the icon view.
I believe it is due to how updates (and clipRects) are handled internally for the two views. For the list, the repaint never overlaps with the frameshadow (and therefore it is not updated), whereas in the icon view, it always overlaps (most likely because the entire viewport is updated). 

So if I assume that the curlpit is the repainting of these shadows, then you would get slower scrolling in icon view than in list view. Which is what is observed ... 

At list, that's my understanding (from the debugging output), which differs quite some from yours. 

By reducing the size of the shadows (to their minimum), I was at least able to significantly reduce the number of repaints (down to 0 in list view, and 1, in icon view, per scroll).
Comment 31 Hugo Pereira Da Costa 2010-09-02 04:39:50 UTC
@christoph
Still: there might be multiple effects at play.
Anything that is slow repainting, including icons, will slow down the scrolling.
Comment 32 Simonas 2010-09-02 10:54:26 UTC
Hi hugo, im Nece228.
I tried skulpture, it has same choppy scrolling as oxygen. I also just compiled and installed oxygen from svn, but the problem still remains :(
Comment 33 pinheiro 2010-09-02 12:02:46 UTC
Simonas can you and the other guys having this problem share your video hardwarelist+ distro+ video driver version?
Comment 34 Simonas 2010-09-02 13:50:11 UTC
pinheiro, i have amd athlon II x2 250 3.0ghz, 2g ddr3 ram, nvidia geforce 9500gt 1gb ram. im using arch linux (altough same happens in kubuntu 10.04), driver version is nvidia 256.53, xorg-server 1.8.1.902, xorg.conf is automatically configured with "nvidia-xconfig". What else i can say?
Comment 35 Hugo Pereira Da Costa 2010-09-02 15:45:23 UTC
@Simonas,

thanks for checking the latest version and sorry it did not help, which in turn really points to the driver, not being able to deal with this painting -the frame inner shadow- efficiently, unlike other drivers. 

@Christian, 

I have another clue that there is indeed a problem with this inner shadow painting
(on top of any other possible issue, like the one you are experiencing with icons):
- select oxygen as a style (and keep system settings open)
- open dolphin
- select another style (and apply)
- select oxygen again (and apply)
Due to a bug in oxygen, after the second apply, the inner shadows are not drawn any more (I still need to fix it).
The observation though (tested yesterday on IRC with someone who had the same issue), is that the scrolling in dolphin is 'normal' again.

Simonas: can you try reproduce the steps above ? For double-checking ? 

And finally, for the fixing, I have another idea that 'might' help make things better, but its rather unlikely and needs a bit of coding ...
Comment 36 S. Christian Collins 2010-09-02 18:14:59 UTC
@Hugo,

I have tried your suggestions and made a video of the results:
http://www.schristiancollins.com/temp/Dolphin%20Scrolling.m4v

Basically, without the inner shadows being drawn, the scrolling is remarkably more smooth (similar to QtCurve).

I can try the SVN Oxygen, but I'm not exactly sure the best way to do that since I am using the Kubuntu packages for KDE4.5.

PS: I apologize for filming my CRT--the scan refresh is annoying to watch, but hopefully you can see what's happening clearly enough.
Comment 37 Hugo Pereira Da Costa 2010-09-02 18:24:58 UTC
Created attachment 51244 [details]
script to retrieve, configure and compile oxygen from svn trunk

@comments #36
Funny, originally, my comment '@christian' in #35 was actually for Christoph (too many letters in common, I guess).
Anyway, thanks for testing. 

As for compiling oxygen from trunk (on any kde distribution starting from 4.3), The script attached does for that for you (provided that you have svn installed and some devel packages).

Beware that it will overwrite your kubuntu oxygen installation, and will get overridden next time you update kubuntu packages.
On the other hand, oxygen in trunk is usually rather robust, since I'm the main developper on it and tend not to commit unstable things.
Comment 38 Hugo Pereira Da Costa 2010-09-02 18:25:46 UTC
PS: at some point I should post my script on my blog :)
Comment 39 Simonas 2010-09-02 18:39:50 UTC
@Hugo, well i tried about ten times now and the results are same, without inner shadow the scrolling is smooth. I also tried your metod.
Comment 40 Hugo Pereira Da Costa 2010-09-02 19:15:54 UTC
ok. So I just committed, in trunk, an option to disable pixmap caching in oxygen (cause I know nvidia has a hard time retrieving pixmaps from caches). This requires updating kdebase/workspace/libs/oxygen (or oxygen/common in the script above), and kdebase/workspace/kstyles/oxygen (or oxygen/style), recompile, run oxygen-settings from terminal and uncheck the 'enable cache' option.

But I have very little hope that it actually fixes anything (especially since the same issue is found with skulpture, which does not have caching as far as I remember). 

Other than that, I'm out of ideas. One must wait for better drivers :-(
I'll leave the bug open though. in case I have a better idea later.
Comment 41 Simonas 2010-09-03 16:17:21 UTC
Well i tried to disable pixmap from caches but that didnt solve the problem. 
I cant think of anything better than removing that feature for now and then readd it when it will work with all drivers. In fact, that this inner shadow difference betwen kde 4.4 and 4.5 is so small, that its almost impossible to see the difference, and seeing how much trouble can cause this small change i dare to say that we dont need this feature for now, because it costs performance.
Comment 42 pinheiro 2010-09-03 16:31:07 UTC
Given that, I do think it make as huge difrence, and I and many other can't reproduce the problem, looks as its restrictided to a small section of nvidia boards, I would say no to remove the feature.
Comment 43 Hugo Pereira Da Costa 2010-09-03 16:32:44 UTC
at #41
I disagree. We will not revert the feature. It seriously improves the style visual overall, so it is a designer decision not to revert it. The fact that the same issue shows up with skulpture means that this is not an oxygen bug, and most likely a driver bug. Not all driver has the issue (my intel does not). 

So we will not change the style because 'some' drivers can't handle it (there are _many_ buggy drivers on the market, and at least as many non-buggy). We have to live with it. 

I'm closing as an upstream (namely driver) bug.
Comment 44 pinheiro 2010-09-03 16:41:41 UTC
just an aditional coment that I do have an nvidia and I dont have any problem...
Same as my ati/amd laptop, so it realy seasm ristricted to a section of nvidia boards.
Comment 45 Alexander 2010-09-03 22:16:18 UTC
I noticed that this inner shadow is not the only factor that affects to the speed of scrolling. Because without it scrolling is just some faster, much faster, but still not fast and smooth, like in 4.4 it was. And this is not relevant to the style, because it works the same slow with qtcurve and with plastic or CDE.

Scrolling also still becomes faster if I will enable previews in a folder with pictures.

This happened with the same system, only KDE was updated. I do not know is it driver issue or not, but I only know that previously it worked as expected and I even do not noticed any visual improvements to spent so much performance for them.
Comment 46 Hugo Pereira Da Costa 2010-09-03 22:23:16 UTC
ok. In fact reopening. 
Reading the comments in details, I think there are two bugs reports in this bug report.

1/ the driver related problem connected to the painting of the inner shadows (in oxygen and skulpture), which is not visible with e.g. plastique (nor bespin, as it uses 'solid' as opposed to 'transparent' shadows).

2/ the lag that is style independent and depends on the content of the view. This may and may not be driver related. 

In any case, for 1/ there is nothing oxygen can do, and for 2/, it is not oxygen related either.

So re-assigning back to dolphin (hope you guys don't mind).
Comment 47 Simonas 2010-09-05 12:51:31 UTC
Then why without inner shadow everything is fine. At least for me, the laggy scrolling is in all applications which uses inner shadow e.g. khotnewstuff, so i dont think its dolphin only issue. And read kde 4.5.1 announcement in dot, you will see that many people are complaining that with bespin everything is snappy and fast, while with oxygen style everything is more laggy.
Comment 48 Hugo Pereira Da Costa 2010-09-07 05:56:10 UTC
> Then why without inner shadow everything is fine. At least for me, the
> laggy scrolling is in all applications which uses inner shadow e.g.
> khotnewstuff, so i dont think its dolphin only issue. And read kde 4.5.1
> announcement in dot, you will see that many people are complaining that
> with bespin everything is snappy and fast, while with oxygen style
> everything is more laggy.

As I tried to explain, there are two bug reports here (not my fault)
The one you complain about, there is nothing we can do about it, its driver 
related. Bespin does not suffer from it because its shadows are actually not 
shadows, they are opaque (try put an icon under the bespin shadow in dolphin, 
and you can see that the shadows are not see-through)
If you try to make real shadows (like oxygen or skulpture do), then you hit 
this bug, which I could tag as "resolved upstream" (again, I tried to make it 
better, but anything I would try would not help you, and I am short of ideas).

Now there is another bug, which correspond to the fact that _dolphin_ is more 
or less laggy depending on the view you select. This one, I believe Christoph 
has a fairly good explanation for it, and this is _not_ an oxygen bug. Thus 
re-assigning. 

Sorry if you suffer from the first bug (and yes, many people do), but its 
because many people have buggy drivers (and many others dont, or do, but 
differently), and no we will not downgrade the style (like e.g. using opaque 
shadows), tu match the poorest driver. 

Hope it makes sense, (and sorry again),

Hugo
Comment 49 Simonas 2010-09-07 15:11:55 UTC
@hugo,
I just tried to make icons in dolphin larger (96 px) and well, i no longer see laggy scrolling in dolphin altough i am using oxygen with inner shadow effect. And i got on conclusion that the reason why when previews are enabled everything is smooth is that previews have bigger icons. When you set big icons in dolphin (no matter if previews are enabled or disabled), the lag is gone! So i guess that issue is betwen inner shadow and dolphin's icons mechanism. That sounds even more weird, anyone can explain me?
Comment 50 Alexander 2010-11-04 16:57:14 UTC
As I wrote before, I had identical icons size in preview mode and in default mode. In the preview mode scrolling worked fine, without preview — bad.

That was earlier, but now, in KDE 4.3.5, I no longer have this problem.
Comment 51 Simonas 2010-11-05 19:22:45 UTC
@Alexander,
I forgot about this bug. Well, for me all the problems are solved since 4.5.2, the scrolling is no more laggy no matter what widget style i am using. If you read changelog you will see that 4.5.2 has faster icon caching, so that was probably the issue. Overall i highly recommend you to try out 4.5.2 or newest 4.5.3, they both dont have that issue
Comment 52 Alexander 2010-11-06 15:11:23 UTC
Oops, sorry, I meant 4.5.3, not 4.3.5 :)
Comment 53 jonathan 2010-11-20 15:23:41 UTC
*** This bug has been confirmed by popular vote. ***
Comment 54 jonas 2011-04-20 03:16:55 UTC
i had this scrolling issue ever since using kde 4, sometimes it had been a bit better, sometimes worse. I'm now using kde 4.6.1 and still experience that laggy scrolling in dolphin. I've used QtCurve ever since, thus my problems cannot be put down to shadows in Oxygen. I'm also using Intel graphics, formerly GMA950, currently thatone that comes with Core I5, therfore no nvidia issues either. It also cannot be (solely) put down to Qt, as scrolling in Gwenview for example is absolutely smooth, even if maximized and many thumbnails visible.
Though, the scrolling speed in dolphin clearly scales with the amount of visible items. If using icon mode with huge icons and non-maximized window, it is smooth. Maximizing the window, scaling the icon size down, and/or switching to detail mode the speed decreases rapidly.
This can also not be put down on CPU power: firefox for example will scroll absolutely smooth despite all the animations that occur within websites, even ajax applications run smooth. If it was for CPU ressources, the latter would definitely suffer most due to the javascript interpretation and html rendering overhead as compared to optimized c++ applications running directly on the machine.
Comment 55 jonas 2011-04-20 03:30:15 UTC
adressing icon caching as a possible cause:
are icons loaded synchronously? if so, i think it would be a good idea to load them in a dedicated thread like gwenview does for the previews.