Re: Steps to get to GTK+ 3.0



On Wed, 4 Jun 2008 10:56:56 +0200 (CEST)
Tim Janik <timj imendio com> wrote:

> On Tue, 3 Jun 2008, Jean-Yves Lefort wrote:
> 
> > On Tue, 3 Jun 2008 13:34:13 +0200
> > Kristian Rietveld <kris imendio com> wrote:
> >
> >> 4. We will completely lose all means to simply access fields by just
> >> dereferencing the structure.  Instead, we will start to use GObject
> >> properties to access this data much more often.  Using g_object_[sg]et()
> >> can become a little tedious.  Therefore we should introduce a couple of
> >> convenience accessors for GObject properties such as g_object_get_int(),
> >> *double(), *string(), etc.
> >
> > Because of the dynamic nature of the GObject property system, this
> > would also bring a substantial performance overhead,
> 
> No, it won't. Simply because the vast majority of widget field accesses
> are not time critical. E.g. reading out GTK_LABEL (widget)->text is something
> that rarely happens more than once or twice per X event being processed.
> So it really doesn't matter whether you use a field access here, a
> simple getter function, a dynamic property accessor or a signal emission
> to figure the value.
> 
> We have only a few cases, where performant field accees is desired, e.g.:
>    GtkWidget *toplevel = widget;
>    while (toplevel->parent)
>      toplevel = toplevel->parent;
> For such cases, where additional overhead could actually show up in the
> profiles, we are providing helper functions, see gtk_widget_get_toplevel().
> 
> > Note that I don't propose to abandon the dynamic access functionality,
> > which is certainly useful and desirable in a number of specific
> > situations. I simply point out that the performance penalty of dynamic
> > access is unjustified for static use.
> 
> Note that most often you can use very simple and fast getter functions
> instead of the dynamic proeprty interface:
>  	G_CONST_RETURN gchar *
>  	gtk_label_get_text (GtkLabel *label)
>  	{
>  	  g_return_val_if_fail (GTK_IS_LABEL (label), NULL);
>  	  return label->text;
>  	}
> 
> Other than that, I'd have to see reproducable performance profiles for
> things claimed to be "unjustifyably" slow, to consider changes/fixes.

I thought that GObject was meant as a general-purpose object system
for C, rather than as a GTK+-specific utility library. I suppose I
misunderstood.

-- 
Jean-Yves Lefort <jylefort brutele be>

Attachment: pgpAzXq5cgc0O.pgp
Description: PGP signature



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