Re: [gtk-list] Re: Widgets Vs Gadgets (Was : map/unmap optimization)

[julian gosnell nomura co uk]

> On Jul 21, Patrice Fortier wrote:
> > > If Gadgets do prove to be lighter in certain situations (I think in Motif
 the
> > >  idea was to use them in menus),
> > 
> > This was the case for motif, athena & co some years ago, but I don't think
> > the problem comes from the menu. The number of entries in a menu is not
> > that large (usually < 100). Anyway, as far as I remember the menu items
> > are widgets, not gadgets (I'm not at home, so I can hardly check this).
> > 
> > The problem may occur with widgets with a huge amount of children, like
> > clist (or even ctree?), which can have +10.000 entries.
> > But I think there are few cases like these (and I hope so, for my 
> > computer memory :)).
>  
> I suspect one of the reasons for using Gadgets was for cases like the
> above - since a Widget (which has an X window) requires server-side
> resource for each instance, whereas a Gadget is client-side.

I suspect that there would be very little difference between realizing 10,000
 node widgets and drawing 10,000 node gadgets - the difference occurs because
 you don't bother to draw the nodes that you can't see. If you only realized the
 node widgets the first time you needed to see them you would miss the initial
 hit and probably be just as fast. A further optimisation, (which would need
 some confirmation) would be to reuse a small group of node widgets to represent
 all nodes by moving them around, altering their characteristics etc.

The real problem here is the the interface to which the user of the toolkit is
 working. If, in order to represent 10,000 nodes, they must immediately create
 10,000 widgets/gadgets then things are bound to be slow - The user may never
 look at more than ten of them. 

In the best GUI toolkits that I have seen, widgets do not hold data at all, they
 simply call back to the user (probably with a clipped window or pixmap) when
 they need the data drawn, the user draws the data however they feel like doing
 so. This has the following advantages :

o prevents multiple copies of same underlying data proliferating around the
 program - I may want to display the same 10,000 rows of a table in different
 formats in different tables - it may have come from a DB in the form of
 INTS/FLOATS etc - it would be really wastefull to have to allocate 10,000
 strings when I may be able to draw an int more efficiently etc...

o since resources are only expended on a pay-as-you go basis, it is a very
 efficient way of doing things.

The problem with all this is that the programmer needs to write his program
 completely differently, in a more event-driven way, but this is what Xt/GTK
 etc. are all about anyway - so what's the problem ?


So in conclusion may I suggest a gtkdrawlist and a gtkdrawntree which work in
 this way. Then you can have as many items as you have swap-space at very little
 extra cost, and the widget vs gadget argument (which is only squabbling over a
 few cycles here and there anyway) pales into insignificance.


As any good LISP programmer will tell you - LISP isn't slow, it's just people do
 things in inefficient ways. The higher the level of abstraction at which you
 are able to optimise, the greater the benefit.



Hope you all have fun with this,




Jules