Re: gtk+ and gtk-engines slow



My thoughts exactly, except that from what Miguel has been saying, it
seems that it caches on a per app basis.  This seems completely illogical,
but who knows.

On Sat, 23 Jan 1999 bratsche@dfw.net wrote:

> 
> I believe Imlib does already cache pixmaps globally, although I've never
> really examined its code before. After all, caching pixmaps on a
> per-application basis really wouldn't be all that useful, especially in
> the situation of a pixmap theme engine. =)
> 
> Cody
> 
> On Sat, 23 Jan 1999, Marcus Brubaker wrote:
> 
> > Take this from someone who has no idea what they're talking about as far
> > as this is concerned, but would it be possible to have a global Imlib
> > cache?  That way we only have one cached copy of all the pixmap images?
> > This seems to make more sense, but it may not be possible.  Maybe it could
> > be done by some sort of imlib-cache-server daemon?
> > 
> > On Sat, 23 Jan 1999, Miguel de Icaza wrote:
> > 
> > > 
> > > > ->  I just tried it as well. It does speed up the computer significantly. :)
> > > > ->  If the cache is so much faster, shouldn't it default to cache instead of
> > > > ->  defaulting to no cache?
> > > > 
> > > > talk to miguel - he believes the cache is useless. I disagree - it is
> > > > why I implimented a cache. I have VERY good reasons for doing stuff
> > > > often - most of the time no-one realises until somehting else goes
> > > > wrong :(.
> > > 
> > > The fix is simple:
> > > 
> > >     in the gtk pixmap theme init code we need to do:
> > > 
> > >     gdk_imlib_get_cache_info (&old_pixmaps, &old_images);
> > >     gdk_imlib_set_cache_info (TRUE, TRUE);
> > > 
> > > And on theme shutdown we need to do:
> > > 
> > >     gdk_imlib_set_cache_info (old_pixmaps, old_images);
> > > 
> > > Mind if I apply this patch to gtk-engines?
> > > 
> > > The reason I dislike the Imlib cache for pixmaps is because for the
> > > non-pixmap case we end up keeping 500k of data around that are
> > > unreleasable.  10 GNOME programs running would ammount to 5 megs of
> > > usually unused and unreleasable information.  30% of most workstation
> > > setups.
> > > 
> > > Miguel.
> > > 
> > > 
> > > -- 
> > >         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
> > >          To unsubscribe: mail gnome-list-request@gnome.org with 
> > >                        "unsubscribe" as the Subject.
> > > 
> > 
> > Marcus Brubaker
> > spoon@elpaso.net
> > http://www.elpaso.net/~spoon
> > 
> > Probably the last man who knew how it worked had been tortured to
> > death years before. Or as soon as it was installed. Killing the
> > creator was a traditional method of patent protection.
> >         -- (Terry Pratchett, Small Gods)
> > 
> > 
> > -- 
> >         FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
> >          To unsubscribe: mail gnome-list-request@gnome.org with 
> >                        "unsubscribe" as the Subject.
> > 
> 

Marcus Brubaker
spoon@elpaso.net
http://www.elpaso.net/~spoon

"There is nothing that can be in our way, for this is Jekub, that Laughs at
Barriers, and says brrm-brrm."
        -- From the Book Of Nome, Jekub, Chap. 3, v. V
           (Terry Pratchett, Diggers)



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