Re: Steps to get to GTK+ 3.0

[Stefan Kost <ensonic hora-obscura de>]

hi,
Brian J. Tarricone schrieb:
> Jean-Yves Lefort wrote:
> > On Wed, 04 Jun 2008 15:18:45 -0400
> > Paul Davis <paul linuxaudiosystems com> wrote:
> >
> > > On Wed, 2008-06-04 at 20:57 +0200, Jean-Yves Lefort wrote:
> > >
> > > > Rather than calling my suggestions silly, why don't you actually try
> > > > to explain how the non-preprocessed, dynamic-only GLib property design
> > > > is superior to the Qt design (or at least not inferior), or describe
> > > > these specific reasons that you are talking about?
> > > because i really don't give a damn. i don't use GTK+, i use gtkmm, and
> > > there is no feature of Qt that i ever find lacking. although Qt has
> > > closed the gap, for a long time it was the poor cousin of gtkmm when it
> > > came to type-safety, integration with the STL and more. i'm really not
> > > all that interested in what happens at the GObject level, other than
> > > that it maps into a decently performing layer by the time i interact
> > > with it at the C++ level. i also don't want to see glib/gobject
> > > developers wasting time trying to do what C++ plus a preprocessor does
> > > in plain C or C plus Yet Another PreProcessor.
> > You didn't get the point. As explained in my initial message, a
> > preprocessor would be used to fix the performance of the property
> > system.
>
> I wouldn't think that this is worth it.  As Tim mentioned elsewhere, for 
> properties that need to be read/written in a time-critical fashion, it's 
> best to add specific getters/setters.  GTK already does this in many 
> places (often for convenience, not for performance reasons), so I don't 
> see how this is a huge burden.
>
> Regardless, have you done any benchmarking?  You might find the 
> performance issues to be negligible.  And you might not.  But throwing 
> around statements like "it's definitely much slower" is meaningless 
> without numbers.

I wrote such a test actualy. Obviously a getter is faster than g_object_get() 
and it was magnitutes. I will attach the figures later once I have found the 
test case.

For the setter vs. g_object_set its not as dramatic as the setter needs to call 
g_object_notify() still. The slow part is the string -> quark and the property 
lookup.

Using g_object_{s,g}et_property vs. g_object_{s,g}et gives only small advantage, 
as one saves the varags loop and some gvalue related things.

For gtk this all might become a bit more serious it an animation system is 
planned. In gstreamer we can 'animate' gobject properties over time (see 
GstController).


To conclude, for those who are worried, lets test and profile and I am sure 
noone rejects patches that improve performance (without making the code ugly) :)

Stefan