You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
101 lines
5.3 KiB
101 lines
5.3 KiB
4 years ago
|
################################
|
||
|
|
# Config file for Imlib #
|
||
|
|
################################
|
||
|
|
|
||
|
|
# The file that contains palette entries for a global palette for all Imlib
|
||
|
|
# based programs.
|
||
|
|
# options: full path to palette file
|
||
|
|
PaletteFile @sysconfdir@/im_palette.pal
|
||
|
|
# This defines if when the display is greater than 8 bit, that it still remaps
|
||
|
|
# the images to the palette defined, rather than using "perfect" rendering
|
||
|
|
# options: yes/no
|
||
|
|
PaletteOverride no
|
||
|
|
# If remapping to the palette, whether 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 turns on dithering for 15/16 bpp. This makes smooth gradients look much
|
||
|
|
# smoother - in fact almost perfect. You will find it nigh impossible to tell
|
||
|
|
# the difference between 15/16bpp dithered and 24bpp. Unless you have extra
|
||
|
|
# CPU to burn, its not recommended, unless you are a image quality freak, and
|
||
|
|
# you insist on maximum quality in 15/16bpp. It does slow things down. It
|
||
|
|
# would be best to leave it off and let the applications themselves allow
|
||
|
|
# you to select it for certain purposes only.
|
||
|
|
HighQuality off
|
||
|
|
# This option if specified off will force MIT-SHM off, otherwise will allow
|
||
|
|
# Imlib to work it out itself.
|
||
|
|
Mit-Shm on
|
||
|
|
# This will turn shared pixmaps on or off (off forces off, on lets imlib
|
||
|
|
# work it out). This is yet another speedup. leave it on unless it doesn't
|
||
|
|
# work.. then turn it off.
|
||
|
|
SharedPixmaps on
|
||
|
|
# This speeds up rendering considerably, but may not work on your hardware
|
||
|
|
# due to it bypassing a few layers and byte-twiddling the rendered image data
|
||
|
|
# manually, and due to endianess, bit-ordering or RGB ordering it may screw up
|
||
|
|
# and not work, so try it.. if things work great!, if not, wait until a
|
||
|
|
# renderer for your situation is written, or write one yourself and donate
|
||
|
|
# it. It's easy to do, just look at rend.c
|
||
|
|
FastRender on
|
||
|
|
# This is in fact a workaround due to Solaris's shared memory theories.
|
||
|
|
# This specifies the maximum size of a shared memory 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, in case the same image is loaded again soon
|
||
|
|
# afterwards. Neat eh?
|
||
|
|
Image_Cache_Size 524288
|
||
|
|
# 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 memory-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 on
|
||
|
|
# 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 with 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, in fact 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 5242880
|
||
|
|
# This FORCES Imlib to use the hexadecimal visual id stated here if it is
|
||
|
|
# defined in the imrc. This bypasses Imlib's routines that hunt for the best
|
||
|
|
# visual. You can obtain a list of visual ID's using the xdpyinfo command.
|
||
|
|
# You should only need this if Imlib doesn't pick the correct visual or you
|
||
|
|
# have strange hardware/Xserver combinations.
|
||
|
|
#ForceVisualID 22
|
||
|
|
# This allows Imlib to fall back on Imagemagick and/or NETPBM
|
||
|
|
# utilities if it can't load the file.
|
||
|
|
Fallback on
|
||
|
|
# Default Gamma, Brightness and Contrast stuff....
|
||
|
|
Gamma 1.0
|
||
|
|
Brightness 1.0
|
||
|
|
Contrast 1.0
|
||
|
|
Red_Gamma 1.0
|
||
|
|
Red_Brightness 1.0
|
||
|
|
Red_Contrast 1.0
|
||
|
|
Green_Gamma 1.0
|
||
|
|
Green_Brightness 1.0
|
||
|
|
Green_Contrast 1.0
|
||
|
|
Blue_Gamma 1.0
|
||
|
|
Blue_Brightness 1.0
|
||
|
|
Blue_Contrast 1.0
|
||
|
|
Ordered_Dither on
|