Re: GtkTreeView: inserting rows faster.

[Jonathan Blandford <jrb redhat com>]

Peter Zelezny <pzel dodo com au> writes:

> > Also, it is (not surprisingly) slower when you
> > have a listener such as a GtkTreeView.
> 
> /timer -repeat 0 1 recv :nick!user host com JOIN :#debian
> /timer -repeat 0 1 recv :nick!user host com PART :#debian
> 
> This simulates one insert/delete once per second, and already it's creating
> quite a heavy load. I've noticed that it re-draws the userlist once
> incorrectly, then correctly. Something like this:
> 
> .------.------------.
> | Icon | Text       |
> )------+------------(
> | N*ck name         |
> | Nickname 2        |
> `-------------------'
> 
> Then it redraws:
> .------.------------.
> | Icon | Text       |
> )------+------------(
> |  *     Nick name  |
> |        Nickname 2 |
> `-------------------'
> 
> It does these two redraws for every 1 row inserted, you can see it
> flicker. Note, some rows don't have an Icon (pixbuf passed in as
> NULL, this might have something to do with it).

Can you possibly reduce this to a standalone test case?  I don't think
I'll be able to efficiently debug it otherwise.

> Admittadly, I have an old GTK (2.0.6 from RH8), but I've had reports
> from people of the high cpu load on 2.2.1 aswell.
> 
> The current calls that cause it are only:
> 
> gtk_list_store_insert_after and
> gtk_list_store_set.

Might be good to retry this with GTK+-2.2.  It has changed a lot since
then.

> > It doesn't.  This code is incredibly complicated, and cannot be
> > described in a paragraph.  It does measure all rows at some point
> > (mostly in an idle.)
> 
> What does it measure, text extents?

Yes.

> > > Ideally, it should be possible to insert rows in constant time when
> > > calling gtk_list_store_insert_(after/before). Is it achievable?
> > 
> > Insert before is not without adding a back pointer.  Also, we need to
> > know the location of rows when we emit the signal.  This does require
> > the walking of the list, but I feel this is prolly fast -- especially as
> > we special case the last row (which is reasonably common.)  We might be
> > able to do a few more special cases, but I'd really like to make sure
> > this is slow first.
> 
> Something in the idle timeout (incremental reflow?) is causing undue
> redraws or cpu usage. If I insert 500 rows in a loop, it doesn't cause
> any more of a cpu hit than inserting 1 row. It's got something to do
> with the icons in Column-0, because I can't reproduce it with a flat
> 1 column list.

Odd.  Unless you're marking the whole tree dirty, or swapping out models
or something, I can't see why that would happen.

Thanks,
-Jonathan