Re: gtk slowness?

[Owen Taylor <owt1 cornell edu>]

Jay Painter <jpaint@serv.net> writes:

> > hm, who is in charge for such a proposal?
> > i'm curious (extremely), in what way do you plan to change the signal
> > emission system?
> > hm, there are so mmuch things involved with signal handling/object methods
> > that i'll better shut up now and wait until i see what you have in mind.
> > but please extend on this jay!
> 
> It's not my proposal/idea, Quartic and Miguel are working on it.  The
> basic idea is to eliminate the widget-defigned signal marshalling by
> having fixed callback arguments.  Somthing like:
> 
> generic_gtk_callback (GtkWidget * widget, 
>                       gint signal_type,
>                       gpointer * data,
>                       gpointer * pointer_to_args_struct)
> 
> this makes creating signals easier, and allows the connecting of multiple
> signals to the same signal handler.  The signal handler can decide how to
> handle the signal based on it's signal_type.

Ugh. Uck. As Tim points out, this is already implemented in a
typesafe manner with the _interp functions. Doing this for all
callbacks would not only break all existing GTK programs, it
would make all new ones horribly unpleasant to read/write.

I rather doubt that marshalling is a big component of slowness
of GTK (which is only slightly slow at a few things, and generally
performs quite well). Before rushing into such things, I would
really like to see a profile of where GTK spends its time. 
My best guess is that the biggest gains would be in reducing
traffic to the server. (Figuring out how to use XMapSubwindows
instead of XMapWindow, etc)

The above would certainly fit into the Knuth quote about premature
optimization being the root of all evil. (or something like that)

                                        Owen