Bug 138912

Summary: alternative color in KListView cause slowness when using KListViewSearchLine in 20k+ items
Product: [Unmaintained] kdelibs Reporter: LuRan <hephooey_dev>
Component: generalAssignee: Stephan Kulow <coolo>
Status: RESOLVED UNMAINTAINED    
Severity: normal CC: cfeck, dima
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:

Description LuRan 2006-12-17 13:16:33 UTC 
Version:           svn snapshot from 3.5 branch (using KDE Devel)
Installed from:    Compiled sources
Compiler:          gcc 4.1.1 with gentoo patches
OS:                Linux

The alternative color feature slow down the painting of the search result considerably, when there is a large 'gap' in the search results. For example, when the results of KListViewSearchLine contain the first 10 items, an the next is the 20000th item. The cpu will go crasy when the 20000 item should be painted. And there seems to be no cache mechanism, any refresh will cause a recalculation of the color.
Comment 1 Bram Schoenmakers 2007-02-25 21:38:00 UTC 
This should be fixed in Qt4/KDE4 I believe.
Comment 2 Bram Schoenmakers 2007-02-25 21:38:57 UTC 
*** Bug 142010 has been marked as a duplicate of this bug. ***
Comment 3 Bram Schoenmakers 2007-02-25 21:39:21 UTC 
*** Bug 126103 has been marked as a duplicate of this bug. ***
Comment 4 tropikhajma 2008-01-02 22:12:19 UTC 
does it mean this will not get fixed in KDE 3.5.x ?