Re: gtk+ and gtk-engines slow

[bratsche dfw net]

Okay, I understand now. Now I'm -really- looking forward to Imlib 2.0. =)
If Imlib 2.0 will be capable of caching a single button.png to be shared
amongst multiple applications using the pixmap engine, that could
potentially save quite a bit of memory.

Cody

On Sat, 23 Jan 1999 raster@redhat.com wrote:

> On 23 Jan, bratsche@dfw.net scribbled:
> ->  
> ->  So when you're running the pixmap theme and set a button pixmap to
> ->  button.png, does each application keep track of its own button.png file?
> 
> yup. due to the fact thats its a bitch to share large chunks of
> constantly chnaging memory between apps.
> 
> ->  
> ->  > youd'e be surprised - turn caching of in imlib then try the picxmap
> ->  > engine - now tunr it back on and try again - as long as you dont use
> ->  > the latest broken gnome-libs you can do this safely and you'll see
> ->  > WORLDs of speed difference - gtk-pixmap engine, E and ee all rely on
> ->  > pixmap caching to get extra performance boosts.
> ->  > 
> ->  > ->  > 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)
> ->  > 
> ->  > -- 
> ->  > --------------- Codito, ergo sum - "I code, therefore I am" --------------------
> ->  > raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
> ->  > Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
> ->  > 218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
> ->  > Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
> ->  > +1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/
> ->  > 
> ->  >               \|/ ____ \|/  For those of you unaware. This face here is in fact
> ->  > 	      "@'/ ,. \@"   a Linux Kernel Error Message.
> ->  > 	      /_| \__/ |_\
> ->  > 		 \__U_/
> ->  > 							   
> ->  > 
> 
> -- 
> --------------- Codito, ergo sum - "I code, therefore I am" --------------------
> raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
> Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
> 218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
> Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
> +1 (919) 929 9443, 801 4392   For pure Enlightenment   http://www.rasterman.com/
> 
>               \|/ ____ \|/  For those of you unaware. This face here is in fact
> 	      "@'/ ,. \@"   a Linux Kernel Error Message.
> 	      /_| \__/ |_\
> 		 \__U_/
> 							   
>