On Fri, Dec 16, 2011 at 10:32 PM, John Lindgren wrote:
> Steve,
>
> I use the "time" shell command and wait for my CPU meter to drop back to
> idle before quitting the test program, giving something like this:
>
> time ./list-test
>
> real 0m31.719s
> user 0m29.168s
> sys 0m0.
Jannis Pohlmann wrote:
> I only briefly read the other replies, so maybe I'm repeating something
> here. One thing I remember that can speed things up drastically is to
> only associate the model with the tree view once it has all its data.
> AFAIR, populating the model while it's linked to the tre
On 12/16/2011 05:54 AM, jcup...@gmail.com wrote:
> ...
>
> I did notice that you forgot to put the treeview into fixed-height mode.
>
> Normally, treeview lets rows vary in height (so you can change font
> between rows, for example). To make this work, treeview has a idle
> task which scans the ent
Steve,
I use the "time" shell command and wait for my CPU meter to drop back to
idle before quitting the test program, giving something like this:
time ./list-test
real0m31.719s
user0m29.168s
sys0m0.023s
-- John
On 12/16/2011 12:24 AM, Steve . wrote:
> John,
>
> Tim
On 16 December 2011 10:36, wrote:
> 2011/12/16 John Lindgren :
>> Lately I have been trying to improve the performance with large
>> playlists (i.e. on the order of 100,000 entries). The one remaining
>> problem spot seems to be GtkTreeView. I am attaching a simple test
>> program that creates
On Thu, 15 Dec 2011 20:13:03 -0500
John Lindgren wrote:
> Hi,
>
> I am the lead developer of Audacious (a GTK+ based music player).
> Lately I have been trying to improve the performance with large
> playlists (i.e. on the order of 100,000 entries). The one remaining
> problem spot seems to be
2011/12/16 John Lindgren :
> Lately I have been trying to improve the performance with large
> playlists (i.e. on the order of 100,000 entries). The one remaining
> problem spot seems to be GtkTreeView. I am attaching a simple test
> program that creates a GtkTreeView with 3 columns and 100,000 r
Steve,
Are you looking at the time it takes to show the window or the time
before the CPU usage drops to idle? GtkTreeView does a lot of work in
the background after the window appears.
-- John
On 12/15/2011 11:17 PM, Steve . wrote:
> John,
>
> I just ran your test on my thinkpadx61, It only t
On 12/15/2011 09:56 PM, Steve . wrote:
> John,
>
> I can't tell you this /will work/. More over this is how I'd first
> approach the problem (maybe I'm way off base here too)
>
> My initial thoughts are that the user can't see 100,000 items at once
> so there is no need to expect the widget to hand
Hi Steve,
I'm not sure that I understand. Are you saying that we should assume
that the user wants access to only part of the playlist and somehow try
to predict what part? This doesn't sound like a good solution to me.
-- John
On 12/15/2011 08:33 PM, Steve . wrote:
> John,
>
> I have no exper
Hi,
I am the lead developer of Audacious (a GTK+ based music player).
Lately I have been trying to improve the performance with large
playlists (i.e. on the order of 100,000 entries). The one remaining
problem spot seems to be GtkTreeView. I am attaching a simple test
program that creates a Gtk
11 matches
Mail list logo