Re: Multi-size, Multi-Bit depth icons

[raster redhat com]

On 16 Jul, James Michael Mastros shouted:
->  On Wed, Jul 15, 1998 at 07:28:54 PM -0400, raster@redhat.com wrote:
->  > On 15 Jul, Ben 'The Con Man' Kahn shouted:
->  > ->  	These reductions are quick -- unless you want anti-aliased
->  > ->  scaling.  Under such conditions, a cache might be a good idea.  Only the
->  > ->  first time is slow.  THEN I suggested a cache which stores information
->  > ->  needed for each scaling op.  This way, scaling to any size is fast.
->  > 
->  > ho - you mean just like imlib's current pixmap caching scheme (that
->  > does exactly this) :) i though u mean take the 640x480 and just use
->  > that instead... :)
->  
->  I think that's what he meant with the caching, yes <G>.  (Though
->  perstistancy might be a Good Thing -- that isn't there now, is it?  Also, is
->  it cross-process?)

what do u mena "persistancy" as in I rener the pixmap at size XxY -
free it go render at another 2 or 3 sizes then try XxY again? and it
then sees its still in the cache and grabs it out of the cache? thats
alreday there :) thats what the pixmpa cache size is for imlib 9run
imlib_config) same for the image cache - tis the "unused pixmas" and
"unused images" caches - when a pixmap or image reaches a reference
count of 0 it's added to this cache (well nto literally but in effect)
if the size of this cachre exceeds the set size imlib sits down and
removes (actually frees) images and pixmaps until the cache is smaller
than or equal to the set size. the bigger your cache the more sizes
imlib will remember for you and simply "drag out of cache" when asked
for again. Imlib may be a bit smarter than you give it credit for (it
does exactly the same wiht images loaded off disk so infact with small
images you can write dumb-ass programs that re-load the same image 5
times and after each load destroys it - the firts load is slow cause
its an actual load the other 4 are almost instant cause imlib simply
increases the referecne count of the image to 1 and bumps to to the
head of the cache list (for faster referencing sicne its a used item it
will eb accessed faster at the front of the list assuming it is
re-used often). programs that aact naievly will be helped along nciely
by imlib. No the cache is not cross-process. This is the plan for Imlib
2.0 - imlib will become a daemon/server process started at login -
Imlib the library will be a frontend with an almost identical api (there
will be a few minor api breakages). The serevr will load images and
render pixmaps and then simpyl hand out pixmap id's to client when they
ask for an image at size XxY - wiht will allow for cross process
sharing of pixmaps (will be a BIG help for thems and icons) and also
will allow much easier things like threading of rendering processes to
take advantage of SMP machines (this may be a while after the move to
the Imlib server architecture tho).

->  However, a quality option bitmap somewhere might be a Good Thing (resizing
->  alogrithim, dithering).  Perhaps even making an intelegent default decision
->  (based on image size)...

it alreday has several render types (quality levels) they include
dithering on or of in 15/16bpp (yes imlib will dither using either
floyd-steinberg or orderd in 15/16bpp if set to the correct render mode
before rendering a pixmap - Enlightenment by default sets the "high
quality" render mode on for this - so does the GNOME background
properties). It also can have dithering turned off (for 8bp etc.) which
is considerably faster but not as nice looking.

->  	-=- James Mastros

-- 
--------------- 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/