Re: Steps to get to GTK+ 3.0

[Jean-Yves Lefort <jylefort@xxxxxxxxxx>]

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, eg:

	- unnecessary dynamic lookup of a pspec whose name and details
	  are known at compile time
	- unnecessary round-trip through GValue
	- for non-virtual properties, unnecessary indirect call
	- unnecessary switch in the global get_property/set_property,
	  as opposed to per-property accessors
	- ...

Have you ever considered switching to a static design? It would
eliminate the unnecessary dynamic overhead, and it would also make it
much easier to implement a GObject. That is, property declarations
would be put into a separate input file, which a simple GObject
compiler would use to generate the relevant C glue.

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.

-- 
Jean-Yves Lefort <jylefort@xxxxxxxxxx>

Attachment: pgplLD37yoUnB.pgp
Description: PGP signature

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