*** empty log message ***

git-svn-id: https://svn.wxwidgets.org/svn/wx/wxWidgets/trunk@12 c3d73ce0-8a6f-49c7-b76d-6d57e0e08775

misc/imlib/imrc

@@ -0,0 +1,99 @@
+################################
+#    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                       /etc/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                     off
+# 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                  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 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                 40000000
+# 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