Re: Steps to get to GTK+ 3.0

[Tim Janik <timj@xxxxxxxxxxx>]

On Tue, 3 Jun 2008, Jean-Yves Lefort wrote:

> On Tue, 3 Jun 2008 13:34:13 +0200
> Kristian Rietveld <kris@xxxxxxxxxxx> 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.

> --
> Jean-Yves Lefort <jylefort@xxxxxxxxxx>

---
ciaoTJ
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-devel-list