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