]>
Commit | Line | Data |
---|---|---|
c801d85f KB |
1 | ################################ |
2 | # Config file for Imlib # | |
3 | ################################ | |
4 | ||
5 | # The file that contains palette entries for a global palette for all Imlib | |
6 | # based programs. | |
7 | # options: full path to palette file | |
cd53f341 | 8 | PaletteFile /etc/im_palette.pal |
c801d85f KB |
9 | # This defines if when the display is greater than 8 bit, that it still remaps |
10 | # the images to the palette defined, rather than using "perfect" rendering | |
11 | # options: yes/no | |
12 | PaletteOverride no | |
13 | # If remapping to the palette, whether to use Floyd-Steinberg dithering. Saying | |
14 | # yes will slow things down though. | |
15 | # options: yes/no | |
16 | Dither yes | |
17 | # when remapping to the palette, saying fast will reduce accuracy, but improve | |
18 | # speed quite considerably | |
19 | # options: fast/slow | |
20 | Remap fast | |
21 | # This turns on dithering for 15/16 bpp. This makes smooth gradients look much | |
22 | # smoother - in fact almost perfect. You will find it nigh impossible to tell | |
23 | # the difference between 15/16bpp dithered and 24bpp. Unless you have extra | |
24 | # CPU to burn, its not recommended, unless you are a image quality freak, and | |
25 | # you insist on maximum quality in 15/16bpp. It does slow things down. It | |
26 | # would be best to leave it off and let the applications themselves allow | |
27 | # you to select it for certain purposes only. | |
28 | HighQuality off | |
29 | # This option if specified off will force MIT-SHM off, otherwise will allow | |
30 | # Imlib to work it out itself. | |
31 | Mit-Shm on | |
32 | # This will turn shared pixmaps on or off (off forces off, on lets imlib | |
33 | # work it out). This is yet another speedup. leave it on unless it doesn't | |
34 | # work.. then turn it off. | |
35 | SharedPixmaps off | |
36 | # This speeds up rendering considerably, but may not work on your hardware | |
37 | # due to it bypassing a few layers and byte-twiddling the rendered image data | |
38 | # manually, and due to endianess, bit-ordering or RGB ordering it may screw up | |
39 | # and not work, so try it.. if things work great!, if not, wait until a | |
40 | # renderer for your situation is written, or write one yourself and donate | |
41 | # it. It's easy to do, just look at rend.c | |
42 | FastRender on | |
43 | # This is in fact a workaround due to Solaris's shared memory theories. | |
44 | # This specifies the maximum size of a shared memory chunk in bytes. If an | |
45 | # image is larger that this in bytes for the video mode you're in, imlib will | |
46 | # not use MIT-SHM. if you comment this out, imlib will use as much memory as | |
47 | # necessary to render the image. | |
48 | # Shm_Max_Size 1000000 | |
49 | # This turns Image loading (24) bit caching on or off. HIGHLY suggested to be | |
50 | # turned ON! | |
51 | Image_Cache on | |
52 | # Image cache size in bytes. As with any cache, the more, the better. If you | |
53 | # load the same image more than once. Imlib will used a previously loaded | |
54 | # copy, and if its freed, the Image_Cache_Size amount of bytes of image data | |
55 | # are kept even after being freed, in case the same image is loaded again soon | |
56 | # afterwards. Neat eh? | |
57 | Image_Cache_Size 4000000 | |
58 | # This turns the pixmap caching system on or off. If on, only well-behaved | |
59 | # programs that conform to the specs for using Imlib will exhibit the | |
60 | # behavior as expected. It is suggested to leave this on, as it will boost | |
61 | # performance considerably, speed-wise and memory-wise. The reason apps need | |
62 | # to be well-behaved is so that they don't go drawing on, and XFreePixmap'ing | |
63 | # these pixmaps themselves, because this will trample all over the cache | |
64 | # and give very horrid effects, or even make the apps crash with segfaults or | |
65 | # Xlib errors. | |
66 | Pixmap_Cache on | |
67 | # Pixmap cache is in **-> BITS <-**... the end result is APPROXIMATELY | |
68 | # 10000000 bits of pixmap make your Xserver grow by 1Mb of RAM (VERY rough). | |
69 | # As with any cache, the more, the better. The more you have, the less likely | |
70 | # it is that you will get cache misses and so performance on scaling the same | |
71 | # image to commonly used sizes (ie if 3 or 4 sizes of the same image are used) | |
72 | # will be lightning fast, in fact in some tests I did, in 16bpp up to 38 times | |
73 | # as fast, and in 8bpp (with dithering on) up to 105 times faster!!! (these | |
74 | # are nominal figures obtained on my machine. these are MAXIMUM speedup | |
75 | # results. Results may vary on other machines and according to the way | |
76 | # programs are written and use Imlib) | |
77 | Pixmap_Cache_Size 40000000 | |
78 | # This FORCES Imlib to use the hexadecimal visual id stated here if it is | |
79 | # defined in the imrc. This bypasses Imlib's routines that hunt for the best | |
80 | # visual. You can obtain a list of visual ID's using the xdpyinfo command. | |
81 | # You should only need this if Imlib doesn't pick the correct visual or you | |
82 | # have strange hardware/Xserver combinations. | |
83 | #ForceVisualID 22 | |
84 | # This allows Imlib to fall back on Imagemagick and/or NETPBM | |
85 | # utilities if it can't load the file. | |
86 | Fallback on | |
87 | # Default Gamma, Brightness and Contrast stuff.... | |
88 | Gamma 1.0 | |
89 | Brightness 1.0 | |
90 | Contrast 1.0 | |
91 | Red_Gamma 1.0 | |
92 | Red_Brightness 1.0 | |
93 | Red_Contrast 1.0 | |
94 | Green_Gamma 1.0 | |
95 | Green_Brightness 1.0 | |
96 | Green_Contrast 1.0 | |
97 | Blue_Gamma 1.0 | |
98 | Blue_Brightness 1.0 | |
99 | Blue_Contrast 1.0 |