Re: GdkDrawable -> GObject
- From: Tim Janik <timj gtk org>
- To: Havoc Pennington <hp redhat com>
- Cc: gtk-devel-list gnome org
- Subject: Re: GdkDrawable -> GObject
- Date: Fri, 19 May 2000 17:36:31 +0200 (CEST)
On 19 May 2000, Havoc Pennington wrote:
>
> Tim Janik <timj@gtk.org> writes:
> > GdkWindowObject.user_data has to die. we've got GObjects around the place
> > now, so there should simply be gdk_{window|drawable}_{set|get}_user_data ()
> > functions that use quarked data for the user_data storage, much like
> > gtk_object_{set|get}_user_data() are just compatibility wrappers nowadays.
> >
>
> We had some efficiency concerns, since this data lookup would happen
> on every event received. What do you think?
currently there's not going to be much more than a single data
pointer stored per window, so we'll have pretty fast lookups.
once people / ports / whatever start to use quarked data on drawables
and the list grows, we'll have the same problem as with widgets, that
is O(n_data_items) access times for worst case scenarios.
that's why for 1.4, GData will be implemented as a sorted array,
that gives us O(log2(n_data_items)) lookup times, bought by
an O(n_data_items/2) memcpy penalty on average per data item installation.
considering that lookups and not installation is the critical code
path for an sane quarked data usage, that panelty is easily bearable.
with O(log2(n_data_items)) access times for window->widget lookups,
there's no need for efficiency concerns for event handling (especially
not if you count the number of lookups we perform on widget's quarked
data lookup per event, which will of course gain the same speed
benefits).
>
> Havoc
>
---
ciaoTJ
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]