Re: Multi-size, Multi-Bit depth icons

["Ben 'The Con Man' Kahn" <xkahn cybersites com>]

On Wed, 15 Jul 1998 raster@redhat.com wrote:

> On 15 Jul, Ben 'The Con Man' Kahn shouted:
> ->  
> ->  	Maybe imlib should support sampling with a cache.  If the image is
> ->  already in the cache at the right size, don't re-render it.  Or, maybe
> ->  there can be a way to cache the sampling information so the operation
> ->  doesn't take as long for each successive render.
> ->  
> ->  (1024x768 --> 800x600 takes a while, but then 640x480 has the image data
> ->  in cache, so it's faster.)
> 
> thats not correct to go into imli it does nto go do approximate scaling
> - it scales exactly to the size you want - i have considered adding
> render types for anti-aliased scaling (ie pixel subsampling and
> supersampling on scale) - it wont be pretty code nor will it be fast.
> currenly it's not ont he top of the priority list for imlib - an imlbi
> server is however, and revers drawable-> RGB is too. (specifically for
> screencapture etc.)

	I'm not suggesting that.  I'm saying you have an image at
1024x768.  This is a very popular image.  Let's say it is the Gnome foot.
:^)  Okay.  Now you want to use this image a LOT, but not always at that
huge size.  Your needs are:

800x600
640x480
10x8

	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.
						-Ben

------------------------------------ |\      _,,,--,,_  ,) ----------
Benjamin Kahn                        /,`.-'`'   -,  ;-;;'
(212) 924 - 2220                    |,4-  ) )-,_ ) /\
ben@cybersites.com --------------- '---''(_/--' (_/-' ---------------
          Meet Linux: Forrest Gump as an operating system.