Re: gtk+ and gtk-engines slow
- From: Kevin Miller <sar original net>
- To: Gnome-list <gnome-list gnome org>
- Subject: Re: gtk+ and gtk-engines slow
- Date: Sat, 23 Jan 1999 18:41:41 -0600 (EST)
or maybe putting a checkbutton in the theme-switcher capplet for "Imlib
Pixmap Caching" or such, that way the user would have it there in the
meantime. I dunno, I'm no coder, just a suggestion.
sar
On Sat, 23 Jan 1999, Marcus Brubaker wrote:
> I'm probably sticking my nose where it doesn't belong (it wouldn't be the
> first time) but it's a shame to see the both of you, both exceptional
> programmers that are obviously quite stubborn, fueding about something
> like this. I'm inclined to side with raster in that hosing the cache
> arbitrarily in such a way is a bad idea, but the happy medium is to set a
> *default* in a config file to turn Imlib caching on or off. I think
> defaulting it to on is a good idea and then those 486 users that can't
> handle the cache can turn it off by hand until someone writes a capplet
> (or modifies one) to do it in a pretty interface. Lets stop bickering and
> just get back to what we all love to do, hacking. :)
>
> On Sat, 23 Jan 1999 raster@redhat.com wrote:
>
> > On 23 Jan, Miguel de Icaza scribbled:
> > ->
> > -> > The solution is to leave caching on. miguel wanted it off by default.
> > -> > All my code I write for Imlib ASSUMES caching - its SO HANDY it means
> > -> > having to write very little intelligent code since all the smarts are
> > -> > handled for me. imlib is a high-level Image loading and display library
> > -> > - not low level. :)
> > ->
> > -> In GNOME we do not assume that. So, that logic that might make sense
> > -> in Englightment is turned off for us.
> > ->
> > -> See my previous post for a solution in the case of the gtk-engines setup.
> >
> > I have reasons for caching - I designed the cache etc. for a very god
> > reasona nd I make use of it in my code. App slike electic Eyes, E,
> > gtk-pixmap theme etc. rely on it for performance reasons. overriding
> > user preferences forcibly in gnome-libs is the most evil thing i've ever
> > seen. all performance issues wiht imlib and gnome hencefore I will deny
> > any responsability for. This is all on your head, not mine. I disagre
> > with you on this and I have my reasons. I will let you bog gnome down if
> > you want.
> >
> > -> Miguel.
> > ->
> > ->
> >
> > --
> > --------------- 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_/
> >
> >
> >
> > --
> > 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
>
> Distrust all men in whom the impulse to punish is powerful.
> -Nietzsche
>
>
>
> --
> FAQ: Frequently-Asked Questions at http://www.gnome.org/gnomefaq
> To unsubscribe: mail gnome-list-request@gnome.org with
> "unsubscribe" as the Subject.
>
------------------------------
If God is One, what is bad?
-- Charles Manson
Death has been proven to be 99% fatal in laboratory rats.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]