tree/list-view slowness
Mike Hearn
m.hearn at signal.QinetiQ.com
Mon Sep 27 03:29:01 CDT 2004
James Hawkins wrote:
> I am currently working on making Kazaa Lite 2.4.3 more usable. The
> most major problem remaining is that when the user chooses to search
> for a file on the network, the program slows almost to a halt and
> becomes mostly unmanageable. The results are displayed in a
> tree/list-view in the right pane [1]. I've looked into both of the
> controls, and it seems like the slowness could be coming from their
> implementation, but even when I set comctl32 to native, the problem
> remains.
Well, if native comctl32 is also slow then it's probably not the
treeview/listview code. From the screenshot there don't seem to be that
many results, I'd be surprised if any treeview control no matter how
badly implemented choked on only a couple of screenfuls of data. The
problem is probably elsewhere.
> Also, I've done a trace+treeview and a trace+listview and
> only treeview api's seem to be called and not listview. Would it be a
> possibility that they implemented their own listview? Can anyone
> describe a method I can use to track down the inefficiency? Thankyou
> for your help.
I don't see any listview in the screenshot, only a treeview. But yes
programs reimplement the common controls all the time, it wouldn't be
surprising.
You could try oprofile if you're on a 2.6 kernel, alternatively just try
hacking bits of code out of Wine to see when things speed up. If the
slowness is in adding the results rather than rendering them, perhaps
it's a message passing speed problem? If the slowness is in rendering
them maybe owner-draw is being used so there is still lots of message
passing going on.
thanks -mike
More information about the wine-devel
mailing list