################################
#    Config file for Imlib     #
################################

# The file that contains palette entries for a golbal palette for all Imlib
# based programs.
# options: full path to palette file
PaletteFile                       @ETCDIR@/im_palette.pal
# This defines if when the display is greater than 8 bit, that is still remaps
# the images to the palette defined, rather than using "perfect" rendering
# options: yes/no
PaletteOverride                   no
# If remapping to the pallette, wether to use floyd-steinberg dithering. Saying
# yes will slow things down though.
# options: yes/no
Dither                            yes
# when remapping to the palette, saying fast will reduce accuracy, but improve
# speed quite considerably
# options: fast/slow
Remap                             fast
# This option if specified off will force MIT-SHM off, otherwise will allow
# Imlib to work it out itself.
Mit-Shm                           on
# This is infacta  wrokaround due to solaris's inadequacies in shared memeory.
# This specifies the maximum size of a shared memeory chunk in bytes. If an
# image is larger that this in bytes for the video mode you're in, imlib will
# not use Mit-Shm.. if you comment this out, imlib will use as much memory as
# necessary to render the image.
# Shm_Max_Size                      1000000
# This turns Image loading (24) bit caching on or off. HIGHLY suggested to be
# turned ON!
Image_Cache                       on
# Image cache size in bytes. As with any cache.. the more, the better. If you
# load the same image more than once.. Imlib will used a previously loaded
# copy, and if its freed, the Image_Cache_Size amount of bytes of image data
# are kept even after being freed, incase the same image is loaded again soon
# afterwards. Neat eh?
Image_Cache_Size                  4000000
# This turns the pixmap caching system on or off., if on, only well-behaved
# programs that conform to the specs for using Imlib will exhibit the
# behavior as expected. It is suggested to leave this on, as it will boost
# performance considerably, speed-wise and memeory-wise. The reason apps need
# to be well-behaved is so that they don't go drawing on, and XFreePixmap'ing
# these pixmaps themselves, because this will trample all over the cache
# and give very horrid effects, or even make the apps crash with segfaults or
# Xlib errors.
Pixmap_Cache                      off
# Pixmap cache is in **-> BITS <-**... the end result is APPROXIMATELY
# 10000000 bits of pixmap make your Xserver grow by 1Mb of RAM (VERY rough).
# As wiht any cache, the more, the better. The more you have, the less likely
# it is that you will get cache misses and so performance on scaling the same
# image to commonly used sizes (ie if 3 or 4 sizes of the same image are used)
# will be lightning fast, infact in some tests I did, in 16bpp up to 38 times
# as fast, and in 8bpp (with dithering on) up to 105 times faster!!! (these
# are nominal figures obtained on my machine. these are MAXIMUM speedup
# results. results may vary on other machines and according to the way
# programs are written and use Imlib)
Pixmap_Cache_Size                 40000000
