summaryrefslogtreecommitdiff
path: root/legacy/evas/README.in
diff options
context:
space:
mode:
authorCarsten Haitzler <raster@rasterman.com>2005-03-04 15:18:45 +0000
committerCarsten Haitzler <raster@rasterman.com>2005-03-04 15:18:45 +0000
commit25dba809f10c34f25593f3fbb3df4480d85abc50 (patch)
tree7a2358781c79e13b9c46ce278ac2b059e8da5ed1 /legacy/evas/README.in
parent17fc7bb20b32da0f4a99ff949d6b0a65733a1689 (diff)
add this
SVN revision: 13613
Diffstat (limited to 'legacy/evas/README.in')
-rw-r--r--legacy/evas/README.in269
1 files changed, 269 insertions, 0 deletions
diff --git a/legacy/evas/README.in b/legacy/evas/README.in
new file mode 100644
index 0000000..195236b
--- /dev/null
+++ b/legacy/evas/README.in
@@ -0,0 +1,269 @@
1Evas @VERSION@
2
3Evas is a clean display canvas API for several target display systems
4that can draw anti-aliased text, smooth super and sub-sampled scaled
5images, alpha-blend objects much and more.
6
7--------------------------------------------------------------------------
8Requires:
9
10 freetype 2.x.x (I want to make this optional)
11
12Optional:
13
14 X11R6
15 DirectFB
16 OpenGL (underway at the moment)
17 Linux
18 Qtopia
19 libpng
20 libjpeg
21 libeet
22 libedb
23
24--------------------------------------------------------------------------
25Evas as of 0.9.9 has a new (and incompatible) API. Why? It's much cleaner
26and more compact. Designed for portable access to different display systems.
27It is also much more optimised internally, uses much less ram than previous
28Evas libraries, and is tiny. Evas when compiled for the Ipaq is a grand
29total of 191Kb (thats all of Evas minus libjpeg, libpng, libz (required for
30libpng), and minus freetype (required for font rendering)). I have plans that
31may involve having an alternative font engine other than freetype to minimise
32requirements, and having a native (optional) image loader for an image
33format that may end up being custom to evas, but will minimise code &
34requirements especially for embedded use.
35
36Evas uses very little RAM too (try profiling it in memprof if you want to
37know) most of the ram allocated, if you look, is for freetype itself,
38image pixel data, and font glyph data. You can't really avoid this, though
39evas tries to share this data as much as possible and not duplicate where it
40can. Feel free to point me at sensible memory optimisations etc. though :) I
41want this baby to be lean, mean tiny, fast and do everything from your
42massive multi-cpu desktop with gobs of ram and disk to a tiny watch.
43
44Evas also supports full UTF-8 for text object strings, thus allowing for
45full internationalised text strings (if your font gives you all the
46characters). I've tested with quite a few fonts and it works quite well.
47Though this requires a unicode compatible font with unicode charmap support
48(cyberbit is quite good actually as a font). For now Evas draws the fonts
49only from left to right, so arabic, hebrew etc. won't display quite right,
50direction-wise, but the charcters do.
51
52--------------------------------------------------------------------------
53if you want to know what options to enable
54./confiugre --help
55
56Notes:
57 the small dither mask is faster on the ipaq, but is not as good looking. on
58 desktop machines it makes no speed difference so only use
59 --enable-small-dither-mask if you are compiling for the ipaq
60 you need at least 1 image loader if you want to load images.
61 gcc 3.0.x on solaris screws up the jpeg code so erroring out doesn't work.
62 use gcc 3.2 on solaris.
63 freetype 2.1.2 is BAD. RedHat 8.0 uses this as do some debain distributions.
64 either downgrade to 2.1.1. freetype 2.1.3 is ALSO BAD, as is 2.0.9. It has
65 glyph metric rendering bugs and glyph geomery query bugs. do not use it.
66 try using 2.0.3. It is known to be stable and work perfectly with Evas.
67
68--------------------------------------------------------------------------
69notes on features:
70
71SCALING:
72--enable-scale-sample
73
74this enables the sampling scaler code. this is the fastest image scaling
75code, but also the lowest quality. when scaling up pixels will become blocky
76and when scaling down you will see shimmering/aliasing artifacts. this is a
77speed vs. quality tradeoff
78
79--enable-scale-smooth
80
81this is the nicest looking scaler that is not that much slower than
82tri-linear, but it looks really good. it also uses mipmaps and is optimised
83heavily. it is recommended to always use this unless you are really
84struggling for speed and are qilling to forego the quality
85
86DITHERING:
87--enable-small-dither-mask
88
89this uses a 4x4 dither mask instead of 128x128. on desktop boxes these days
90(pentium, pentium2, amd etc.) the speed difference is not really measurable,
91but the quality of the 128x128 dither mask is quite a lot better. patterns
92of dithering are much less noticable, so it is recommended to not enable
93this unless you are struggling for speed. the compaq ipaq for example shows
94a slowdown with this large a dither mask so enabling a small dither mask is
95recommended unless you really want to forego the speed.
96
97ENGINES:
98--enable-software-x11
99
100this enables the software x11 rendering engine that renders to X drawable
101targets using highly optimised software routines. there is no hardware
102assist here. this engine requires X11 to be installed to build (and run).
103This si a godo generic engine that is fast and can run in X for good
104development and debugging purposes.
105
106--enable-fb
107
108this is the software framebuffer drivign engine. this uses the linxu
109framebuffer device (/dev/fb<x>) and will currently just inherit the current
110framebuffer settings on the fb device and use them to run in. this engine is
111almost fully functional except for the fb management itself. i'd be quite
112happy for people to help out with fixing up the fb init & management code to
113properly set up a vt and release it etc. this engine is specifically geared
114towards peoel writing minimalist display systems for embedded devices such
115as the ipaq, zaurus, etc. it also scales up to high-res desktop systems as
116well and performs outstandingly. i have measured up to 67% speedup over X11
117using the fb driver insetad of X11.
118
119--enable-direcfb
120
121this is the direct fb engine that uses direcftb (http://www.directfb.org) on
122linux to access the framebuffer with (or maybe without) acceleration. for
123people making set-top boxes or just wanting an alternative to X this is
124really good. it may also be useful for embedded devices supported by
125directfb that offer acceleration (otherwise the fb driver will likely be
126faster).
127
128CPU:
129--enable-cpu-c
130
131this enabled the c code. you can actually build the code withotu the c
132fallback code and only have the mmx routines for example. it is suggested to
133always use this regardless uness you have some definite size issues with the
134code.
135
136--enable-cpu-mmx
137
138this enables the mmx optimised routines. this works for penitum, pentium2,
139pentium3, pentium4, athlon and duron processors. it can get quite
140considerable speedups, souse it if you can. ppc owners just have to live with
141the c fallback functions unfortunately as no one has provided any ALTIVEC asm
142routines yet. :) arm owners will also have to rely on the c fallback
143routines as i haven't managed to come up with any arm assembly that actually
144can beat the c code (when compiled whht all optimisations) in speed.
145
146--enable-cpu-sse
147
148this enables sse optimisations availbale in he pentium3 and 4 cpus (not
149athlon and duron or pentium 2 or pentium cpu's). ppc owners just have to
150live with the c fallback functions unfortunately as no one has provided any
151ALTIVEC asm routines yet. :) arm owners will also have to rely on the c
152fallback routines as i haven't managed to come up with any arm assembly that
153actually can beat the c code (when compiled whht all optimisations) in speed.
154
155IMAGE LOADERS:
156--enable-image-loader-png
157
158this enables the loader code that loads png files using libpng. there may be
159call for embedded devices later that have custom written small image
160loaders that use sless disk space than libpng to load custom format images.
161for now this is the only loader so you may as well include it.
162
163--enable-image-loader-jpeg
164
165this enables the loader code that loads jpeg files using libjpeg.
166
167CONVERTERS:
168--enable-convert-16-rgb-565
169
170the most common converter you'll want for 16bpp. this means 5 bits for red,
1716 bits for green and 5 bits for blue are used.
172
173--enable-convert-16-rgb-555
174
175this is a converter for what many people know as "15 bit" color. you might
176want to enable this for X output as it used to be common to find many cards
177that do this.
178
179--enable-convert-16-rgb-444
180
181this converter outputs to 12bit packed (int 16 bit WORDS).
182
183--enable-convert-16-rgb-ipq
184
185this converter was written specifically for the ipaq (and may apply to
186similarly configured devices) because it lies about its screen depth. it
187says it is 16bit 565 (that means 5 upper bits of the WORD are red, the next 6
188bits are for green abd the next 5 for blue) but in fact only the upper 4
189bits of each color component (red green and blue) are significant and work,
190so effectively the display is 12 bits of color, not 16, but padded out to
191fill 16bits, with unused bits in the color masks. X on the ipaq advertises
192it as a full 16bpp 565 display (i can't remember what the linux framebuffer
193advertised it as) and so many lumps of code can be fooled into rendering
194data badly because they think the output will look as the expect. This
195renderer assuems the upper 4 bits fo each color primitie only are
196significant and renders accordingly. this produces nice quality images on
197the ipaq and even still works in 16bpp 565 on your pc. it is highly
198recommended to use this renderer if your target is an ipaq or your device
199dislpays similar qualities of the ipaq for display purposes.
200
201--enable-convert-16-rgb-rot-0
202
203this enables the 16bpp converters to run with 0 degrees rotation - this is
204normal disp;ay and you shoudl really include this (though it is optional if you
205only ever want to do portrait mode - perhaps like on an ipaq embedded device)
206
207--enable-convert-16-rgb-rot-270
208
209this enables the portrait mode (270 degree rotation) converteres for 16bpp.
210this is the standard display mode for things like pocketpc on the ipaq and
211the zaurus etc. thsi si a optimised part of the rendering pipeline to allow
212portrait display with a much lower overhead than doing it through X.
213
214--enable-convert-24-rgb-888
215
216To be documented...
217
218--enable-convert-24-bgr-888
219
220To be documented...
221
222--enable-convert-32-rgb-8888
223
224To be documented...
225
226--enable-convert-32-bgr-8888
227
228To be documented...
229
230--enable-convert-32-rgb-rot-0
231
232To be documented...
233
234--enable-convert-32-rgb-rot-270
235
236To be documented...
237
238...
239
240
241------------------------------------------------------------------------------
242COMPILING AND INSTALLING:
243
244 ./configure
245 make
246(as root unless youa re installing in your users directories):
247 make install
248
249------------------------------------------------------------------------------
250BUILDING PACKAGES:
251
252RPM: To build rpm packages:
253
254 sudo rpm -ta @PACKAGE@-@VERSION@.tar.gz
255
256You will find rpm packages in your system /usr/src/redhat/* dirs (note you may
257not need to use sudo or root if you have your own ~/.rpmrc. see rpm documents
258for more details)
259
260DEB: To build deb packages:
261
262 tar zvf @PACKAGE@-@VERSION@.tar.gz
263 cd @PACKAGE@-@VERSION@
264 dpkg-buildpackage -us -uc -rfakeroot
265 cd ..
266 rm -rf @PACKAGE@-@VERSION@
267
268You will find all the debian source, binary etc. packages put in the directory
269where you first untarred the source tarball.