[gtk-list] Re: map/unmap optimization

[Patrice Fortier <Patrice Fortier aquarel fr>]

> > BTW, I sent a patch to gimp.org for the dev tree (1.1?) to add
> > a widget->window to the *frame widgets, as these widgets
> > are drwing in their parent window (which can not be considered
> > a good thing, IMHO).
> 
> why not? there are two type of widgets wrt the windows the use:
> widgets that don't need an own xwindow i.e. NO_WINDOW widgets like
> GtkArrow or GtkBox, and the widgets that introduce at least one
> own x/gdk window i.e. GTK_WIDEGT_NO_WINDOW(widget)==FALSE.

Agreed.
BTW, in the tutorial, gtkitem is said to be a NO_WINDOW, it is not.


> GtkFrame is a NU_WINDOW widget, and thus it is supposed to draw
> into its parent's window.

Yes, and my question is why?
Why does a large, _container_ widget such as the *frame widgets
draw on their parent widgets? (except "it is a NO_WINDOW widget" :))

The main reason for this behaviour is the overhead created by the
(main) window of the widget. This may be critical when you need 
to create/handle a _lot_ of small widgets (say 10000) like 
the entries of a list widget.
For this reason, some wigets sets use gadgets, which are just the
same a the widgets, but without the (X) window. Some other widget
sets create special widgets which handle their own children (entries
in our case), gtkclist comes to mind.

In the current version (1.0), we have both cases. So we need to 
handle them both, and so we get the drawbacks of both solutions.

 - We need to handle each widget/child as if it _could_ be a
   NO_WINDOW widget.

 - Jay had to create the clist widget to get an efficient list 
   widget (id for ctree). Now we have 2 list widgets:
   gtklist and gtkclist.

 - We have a bad designed widget set for X wondow handling (even
   the Athena widgets have a main window - critical widgets like
   entries have _also_ a gadget version).

Gtk is the only toolkit I know that considers that it is normal 
for its widgets to write on other widgets (even for containers
like frame widgets).
Do I need to say that the Athena work on a 386 or a sparc 1?

Another point is that for the theming stuff, Raster will need
a window for the *frame widgets. At least he'll find it _very_
useful:).


Here are some ideas, some should be done, and some other are
just food for thoughts (as they won't please everybody) :)

 - Big container widget that draw on other widgets (ie: parents)
   should draw in their own window.
   The overhead induced by this new window is peanuts, and this
   is _much_ cleaner.
   I think *frames are the only ones, but I'm not sure...

 - next step: all the container should have their own window
   (*box...). this is food for thoughts, don't flame :).
   The overhead created by the window structure, should not
   be important, no expose event is generated by these
   widgets, and this should allow us to get rid of the 3/4 of
   if (NO_WINDOW(xxx)) thing (like expose events, un/map events...).
   The code should be much clean and maybe faster.

 - think about the simple widgets (widget/gadget thing) to 
   find a clean and effcient solution.

BTW, what is the advantage of using gtkpixmap instead of gdkpixmap?


Back on the map/unmap stuff
> also it needs to unmap its child if
> itself gets unmapped, because its child might be a !NO_WINDOW
> widget.

Why?
I mean, why do you need to unmap the child if it's a !NO_WINDOW
widget? This case is handled by X, and the (X) map/unmap functions
are here to handle this case. So why do we duplicate the work?

Maybe there is a reason for this duplication, but I just can't
see what it is.


Patrice.