Bug 138912 - alternative color in KListView cause slowness when using KListViewSearchLine in 20k+ items
Summary: alternative color in KListView cause slowness when using KListViewSearchLine ...
Status: RESOLVED UNMAINTAINED
Alias: None
Product: kdelibs
Classification: Unmaintained
Component: general (show other bugs)
Version: unspecified
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: Stephan Kulow
URL:
Keywords:
: 126103 142010 (view as bug list)
Depends on:
Blocks:
 
Reported: 2006-12-17 13:16 UTC by LuRan
Modified: 2011-10-28 12:36 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:

Attachments
Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
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 ?