Re: Multi-size, Multi-Bit depth icons

[raster redhat com]

On 16 Jul, Yo 'Ric Dude shouted:
->  raster@redhat.com wrote:
->  
->  [snip all kinds of fun stuff here]
->  
->  > ->  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.
->  
->  I think the gist here is a feature request along the lines of 
->  mipmapping.  Anti-aliasing a large pixmap down to icon size may
->  sound good in theory, but frequently, the end product is little
->  more than a blur.  Maybe allow caching of different "sizes" of 
->  the same image, and have imlib scale the closest/best match as 
->  needed?  

basically it's still pixel sub and super-sampling.. somehtng whic i'm
loahte to write all the code for right now. it'll be considerably
slower (tho mip-mappign an dusing plian scaling on pre-mip-mapped data
will give better results at theexpense of more ram - pre-mip-mapped
images can be built "on demand" but scaling UP will eithre have to still
be blocky or slow... - now remember we can scale withotu respect to
keepsing aspect ratios.. so mip-mappign becomes less useful...........
and then there's all the code to handle it.. oh FUN (that is to write ti
ANd make it fast).) First task is to add drawable->imlibImage conversion
 then after than move to a server architecture for imlib - THEn AFTER
 that we can start looking at adding anti-aliased scaling (beofre this
 i'd want to add a faster scaler that i have in mind alreday - lower
 quality but possibly twice as fast or faster in some situations - i
 have had this one in mind for a while).

->  
->  > ->      -=- James Mastros
->  
->  > raster@rasterman.com
->  
->  -- ebm
->  +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+
->  |  __                         a.k.a. Eric B. Mitchell |
->  |  |_) .  _  _|      _|  _     ericmit@ix.netcom.com  |
->  |  | \ ( (_ (_| (_| (_| (/_   www.netcom.com/~ericmit |
->  | How's My Programming?   Call:  1 - 800 - DEV - NULL |
->  +=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=+

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