Re: [gtk-list] Re: list speed



On Fri, 24 Oct 1997, Raph Levien wrote:

> 
> 
> On Fri, 24 Oct 1997, Sascha Ziemann wrote:
> 
> > Hi,
> > 
> > I wrote a program that shows the X11 colors from rgb.txt. My rgb.txt is
> > 750 lines long and so the list contains 750 items. The resize of that
> > window takes 2 secs on a AMD K6 200. I think that is really slow. Is
> > that normal for a GTK program? I use the Guile-GTK bindings and I am
> > wondering weather it is GTK or because of the Guile-GTK layer that makes
> > it so slow.
> > 
> > You can get the program here:
> > http://www.ping.de/sites/aibon/Programme/GNOME/Colorbrowser/
> 
> I haven't downloaded this program, but I have also noticed a performance 
> problem with lists in GTK.

[snip]

> So it seems likely that the problem is in Gtk rather than the Guile
> bindings. 
> 
> Also, you're lucky your database only contains 750 items. If it contained 
> more than about 2200, then the list would be more than 32767 pixels tall, 
> which would cause overflows in both Gtk and X, causing the list not to be 
> displayed properly.
> 
> I'm not sure what's the best solution to these problems. One possibility 
> to consider is to redo the list widget in the Gzw (Gzilla widget) 
> framework. This framework does propagate mouse events from containers to 
> their children, and also handles scrolling of 32 bit pixel dimensions 
> rather than 16 bit. I believe it would offer a dramatic performance 
> advantage in specific situations including large scrolling lists. On the 
> downside, it's not ready yet (I've got it partially working, but not 
> ready for release), and it's not clear to me that it's worth loading down 
> Gtk with an alternate widget framework.

I do not know exactly how you have acheived these enhancements, but
perhaps you/we should consider merging them back into the standard GTK
distro.  If it is possible to do so.. If you're improved widgets are that
much faster and can break the 32767 barrier, maybe it would be better to
have them as replacements (or write replacements using your techniques).


Just a thought,

Ian



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]