Re: Using GParam in GtkTLCell.

On Thu, 31 Aug 2000 jrb redhat com wrote:

> <This email is mostly directed to Tim, but I'm posting it here for
>  posterity's sake>

though meanwhile we actually had a chance to talk about
the issue at hand in person, i'm replying here, since
some responses might still be of general interest.

> 1) I will be doing this every expose event, and in the initial
>    calculation of height stage.  I assumed (perhaps incorrectly) that
>    measuring/rendering text and the model lookup would be the slow step,
>    but given that I may doing a number of g_object_set_param's per cell,
>    I'd like to get an idea of how fast it is.  Tim, could you check in
>    your modified copy of Havoc's benchmark program so we could add some
>    tests of this.

i haven't yet modified havoc's testprogram in that regard,
i'm planning to do some major profilings once most of the
whoe system (including the GSignal stuff) is actually in
place ("place" being CVS HEAD ;)
however, as long as you don't get into the range of doing
a couple of thousand parameter/value operations per eye-blink
of the user, i don't expect major noticable slowdowns with
your approach.

> 2) Tim, why is GValue:
> struct _GValue
> {
>   /*< private >*/
>   GType		g_type;
>   /* public for GTypeValueTable methods */
>   union {
>     gint	v_int;
>     ...
>     gpointer	v_pointer;
>   } data[4];
> };
>          ^ an array of size 4?
> Am I missing something here?  You only seem to use the first one.  The
> reason I ask is that I would like to have the model fill in a GValue
> when queried.  As a result, I was going to store the data for the model
> as the data field of the GValue, but would rather not have it be any
> bigger then it has to be.

the GValue structure is actually just meant to be used for
short term value transfers, that is passing them around to
callers and the like.
as such, values around are mostly going to be stored on the
stack, i.e. in automatic variables, so another 1 or 2 pointers
shouldn't be much of an issue.
you probably do not want to use GValue as the actuall storage
backend for your model, model storage is usually implemented
in pretty specific terms of what you actually want to model
(i.e. something you'd represent as intergers/strings/etc).
as for why the GValue structure's data actually preserves
more room than just one MAX (sizeof (gpointer), sizeof(gdouble)),
that's mostly a backwards compatibility issue, as GValues have
to be as capable as GtkArg in terms of storage facilities.

> Thanks,
> -Jonathan


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