diff options
author | David Walter Seikel | 2012-01-04 18:41:13 +1000 |
---|---|---|
committer | David Walter Seikel | 2012-01-04 18:41:13 +1000 |
commit | dd7595a3475407a7fa96a97393bae8c5220e8762 (patch) | |
tree | e341e911d7eb911a51684a7412ef7f7c7605d28e /libraries/evas/README | |
parent | Add the skeleton. (diff) | |
download | SledjHamr-dd7595a3475407a7fa96a97393bae8c5220e8762.zip SledjHamr-dd7595a3475407a7fa96a97393bae8c5220e8762.tar.gz SledjHamr-dd7595a3475407a7fa96a97393bae8c5220e8762.tar.bz2 SledjHamr-dd7595a3475407a7fa96a97393bae8c5220e8762.tar.xz |
Add the base Enlightenment Foundation Libraries - eina, eet, evas, ecore, embryo, and edje.
Note that embryo wont be used, but I'm not sure yet if you can build edje without it.
Diffstat (limited to 'libraries/evas/README')
-rw-r--r-- | libraries/evas/README | 868 |
1 files changed, 868 insertions, 0 deletions
diff --git a/libraries/evas/README b/libraries/evas/README new file mode 100644 index 0000000..dd87eef --- /dev/null +++ b/libraries/evas/README | |||
@@ -0,0 +1,868 @@ | |||
1 | Evas 1.1.0 | ||
2 | |||
3 | ****************************************************************************** | ||
4 | |||
5 | FOR ANY ISSUES PLEASE EMAIL: | ||
6 | enlightenment-devel@lists.sourceforge.net | ||
7 | |||
8 | ****************************************************************************** | ||
9 | |||
10 | Requirements: | ||
11 | ------------- | ||
12 | |||
13 | Must: | ||
14 | libc | ||
15 | libm | ||
16 | eina (1.1.0 or better) | ||
17 | freetype (2.1.9 or better) | ||
18 | |||
19 | Recommended: | ||
20 | libX11 + libXext + libXrender | ||
21 | OpenGL2.0 or OpenGL-ES 2.0 | ||
22 | fontconfig | ||
23 | libpng | ||
24 | libjpeg (6.0 or better) | ||
25 | eet (1.5.0 or better) | ||
26 | firbidi | ||
27 | harfbuzz | ||
28 | liblinebreak | ||
29 | |||
30 | Optional: | ||
31 | XCB SDL OpenGL librsvg libtiff libgif edb DirectFB evas_generic_loaders | ||
32 | |||
33 | Evas is a clean display canvas API for several target display systems | ||
34 | that can draw anti-aliased text, smooth super and sub-sampled scaled | ||
35 | images, alpha-blend objects much and more. | ||
36 | |||
37 | Evas is designed to be portable to different display systems. Evas uses very | ||
38 | little RAM too (try profiling it in memprof if you want to | ||
39 | know) most of the ram allocated, if you look, is for freetype itself, | ||
40 | image pixel data, and font glyph data. You can't really avoid this, though | ||
41 | evas tries to share this data as much as possible and not duplicate where it | ||
42 | can. Feel free to point me at sensible memory optimizations etc. though :) I | ||
43 | want this baby to be lean, mean tiny, fast and do everything from your | ||
44 | massive multi-cpu desktop with gobs of ram and disk to a tiny watch. | ||
45 | |||
46 | Evas also supports full UTF-8 for text object strings, thus allowing for | ||
47 | full internationalized text strings (if your font gives you all the | ||
48 | characters). I've tested with quite a few fonts and it works quite well. | ||
49 | Though this requires a unicode compatible font with unicode charmap support | ||
50 | (cyberbit is quite good actually as a font). For now Evas draws the fonts | ||
51 | only from left to right, so arabic, hebrew etc. won't display quite right, | ||
52 | direction-wise, but the characters do. | ||
53 | |||
54 | ------------------------------------------------------------------------------ | ||
55 | COMPILING AND INSTALLING: | ||
56 | |||
57 | ./configure | ||
58 | make | ||
59 | (as root unless you are installing in your users directories): | ||
60 | make install | ||
61 | |||
62 | if you want to know what options to enable | ||
63 | ./configure --help | ||
64 | |||
65 | Evas's rendering code assumes a decently optimizing compiler. For | ||
66 | example gcc with -O2 -march=nocona for example (compile for core2 duo | ||
67 | x86 or better). You may choose not to compile for a very modern | ||
68 | architecture, and Evas still has MMX/SSE, NEON and other hand-crafted | ||
69 | assembly, but not for everything, so make use of your compiler | ||
70 | optimizing as much as possible. At least use -O2 or equivalents. | ||
71 | |||
72 | Notes: | ||
73 | the small dither mask is faster on the ipaq, but is not as good looking. on | ||
74 | desktop machines it makes no speed difference so only use | ||
75 | --enable-small-dither-mask if you really need the speed for low depth | ||
76 | you need at least 1 image loader if you want to load images. | ||
77 | gcc 3.0.x on solaris screws up the jpeg code so erroring out doesn't work. | ||
78 | use gcc 3.2 on solaris. | ||
79 | |||
80 | notes on features (--enable-FEATURE enables it and --disable-FEATURE | ||
81 | disables it, some being enabled or disabled by default or if | ||
82 | dependencies are found): | ||
83 | |||
84 | |||
85 | ------------------------------------------------------------------------------ | ||
86 | SCALING: | ||
87 | --enable-scale-sample | ||
88 | |||
89 | this enables the sampling scaler code. this is the fastest image scaling | ||
90 | code, but also the lowest quality. when scaling up pixels will become blocky | ||
91 | and when scaling down you will see shimmering/aliasing artifacts. this is a | ||
92 | speed vs. quality tradeoff | ||
93 | |||
94 | |||
95 | --enable-scale-smooth | ||
96 | |||
97 | this is the nicest looking scaler that is not that much slower than | ||
98 | tri-linear, but it looks really good. | ||
99 | |||
100 | |||
101 | ------------------------------------------------------------------------------ | ||
102 | DITHERING: | ||
103 | --enable-small-dither-mask | ||
104 | |||
105 | this uses a 4x4 dither mask instead of 128x128. on desktop boxes these days | ||
106 | (pentium, pentium2, amd etc.) the speed difference is not really measurable, | ||
107 | but the quality of the 128x128 dither mask is quite a lot better. patterns | ||
108 | of dithering are much less noticeable, so it is recommended to not enable | ||
109 | this unless you are struggling for speed. the compaq ipaq for example shows | ||
110 | a slowdown with this large a dither mask so enabling a small dither mask is | ||
111 | recommended unless you really want to forgo the speed. | ||
112 | |||
113 | |||
114 | --enable-line-dither-mask | ||
115 | |||
116 | this is a faster alternative to the small or large dither masks above. | ||
117 | this dithers only on an alternating-line basis. this only provides 1 | ||
118 | intermediate "dither" level whose odd and even pixels alternate | ||
119 | between the 2 closest colors available, but it is very fast. almost as | ||
120 | fast as no dithering. quality though will not be as good as small or | ||
121 | default "large" dither masks. | ||
122 | |||
123 | |||
124 | --enable-no-dither-mask | ||
125 | |||
126 | this disables dithering entirely. this is the fastest option, but the | ||
127 | lowest quality. not suggested in general unless you are really in need | ||
128 | of an extra few percent speed and are willing to have fairly awful | ||
129 | quality. but in general this is the standard rendering for most | ||
130 | "realtime graphics" if it has to drop to lower bit-depths, so it's | ||
131 | not anything unusual. just in the evas world the quality is considered | ||
132 | poor enough to be discouraged as evas's internal rendering is so much | ||
133 | higher quality. | ||
134 | |||
135 | |||
136 | ------------------------------------------------------------------------------ | ||
137 | ENGINES: | ||
138 | |||
139 | All engines can be compiled statically inside libevas.so in order to | ||
140 | reduce runtime time at dynamically loaded modules. All you have to do | ||
141 | is to enable your chosen modules with "=static" suffix. If they depend | ||
142 | on software_generic (most do), you need that as well. Examples: | ||
143 | |||
144 | ./configure --enable-static-software-generic --enable-software-xlib=static | ||
145 | |||
146 | |||
147 | --enable-software-xlib[=static] | ||
148 | |||
149 | this enables the software x11 rendering engine that renders to X drawable | ||
150 | targets using highly optimized software routines. there is no hardware | ||
151 | assist here. this engine requires X11 to be installed to build (and run). | ||
152 | This is a good generic engine that is fast and can run in X for good | ||
153 | development and debugging purposes. | ||
154 | |||
155 | |||
156 | --enable-software-xcb[=static] | ||
157 | |||
158 | this enable the software xcb rendering engine. It allows the same | ||
159 | features than the software xlib engine. It require the XCB and XCBImage | ||
160 | libraries. For the test programs, XCBICCCM is also needed. It is not | ||
161 | recommended to use this as it's experimental and will create problems | ||
162 | with both ecore_evas and enlightenment itself. | ||
163 | |||
164 | |||
165 | --enable-fb[=static] | ||
166 | |||
167 | this is the software framebuffer driving engine. this uses the linux | ||
168 | framebuffer device (/dev/fb{X}) and will currently just inherit the current | ||
169 | framebuffer settings on the fb device and use them to run in. this engine is | ||
170 | almost fully functional except for the fb management itself. this engine is | ||
171 | specifically geared towards people writing minimalist display systems for | ||
172 | embedded devices such as the ipaq, zaurus, etc. it also scales up to high-res | ||
173 | desktop systems as | ||
174 | well. | ||
175 | |||
176 | |||
177 | --enable-directfb[=static] | ||
178 | |||
179 | this is the direct fb engine that uses direcftb (http://www.directfb.org) on | ||
180 | linux to access the framebuffer with (or maybe without) acceleration. for | ||
181 | people making set-top boxes or just wanting an alternative to X this is | ||
182 | really good. it may also be useful for embedded devices supported by | ||
183 | directfb that offer acceleration (otherwise the fb driver will likely be | ||
184 | faster). as such this engine is in relative disrepair and is not | ||
185 | maintained. use with great care. | ||
186 | |||
187 | |||
188 | --enable-buffer[=static] | ||
189 | |||
190 | this enables the memory buffer rendering engine. this engine renders | ||
191 | to a region of memory that is considered to be a 32bit ARGB buffer of | ||
192 | pixels, allowing the results of rendering to be directly read out or | ||
193 | used again for other purposes. | ||
194 | |||
195 | |||
196 | --enable-gl-x11[=static] | ||
197 | |||
198 | this is the opengl engine. it is intended for an x11 target (via xlib) | ||
199 | rather than framebuffer (even if you use EGL, the EGL flavor is | ||
200 | expected to be an x11 one). it is a full opengl based rendering engine | ||
201 | with all rendering implemented as a texture + triangle pipeline and | ||
202 | more. it also supports opengl-es2.0 and is reliant on modern opengl2.0+ | ||
203 | shader support. this engine also supports the native surface api for | ||
204 | adopting pixmaps directly to textures for compositing. | ||
205 | |||
206 | some environment variables that control the opengl engine are as | ||
207 | follows: | ||
208 | |||
209 | export EVAS_GL_INFO=1 | ||
210 | set this environment variable to enable output of opengl information | ||
211 | such as vendor, version, extensions, maximum texture size etc. unset | ||
212 | the environment variable to make the output quiet again. | ||
213 | |||
214 | export EVAS_GL_MEMINFO=1 | ||
215 | set this environment variable to enable dumping of debug output | ||
216 | whenever textures are allocated or freed, giving the number of | ||
217 | textures of each time and how many kb worth of pixel data are | ||
218 | allocated for the textures. unset it again to stop this dumping of | ||
219 | information. | ||
220 | |||
221 | export EVAS_GL_WIN_RESURF=1 | ||
222 | set this environment variable to enable the gl engine to try and | ||
223 | ddelete the window surface, if it can, when told to "dump resources" | ||
224 | to save memory, and re-allocate it when needed (when rendering | ||
225 | occurs). unset it to not have this behavior. | ||
226 | |||
227 | export EVAS_GL_CUTOUT_MAX=N | ||
228 | set this environment variable to the maximum number of rectangles | ||
229 | applied to a rendering of a primitive that "cut away" parts of that | ||
230 | primitive to render to avoid overdraw. default is 512. unset it to use | ||
231 | defaults, otherwise set N to the max value desired or to -1 for | ||
232 | "unlimited rectangles". | ||
233 | |||
234 | export EVAS_GL_PIPES_MAX=N | ||
235 | set the maximum number of parallel pending pipelines to N. the | ||
236 | default number is 32 (except on tegra2 where is it 1). evas keeps 1 (or more) | ||
237 | pipelines of gl draw commands in parallel at any time, to allow for merging | ||
238 | of non-overlapping draw commands to avoid texture binding and context | ||
239 | changes which allows for more streamlining of the draw arrays that are | ||
240 | filled and passed to gl per frame. the more pipelines exist, the more | ||
241 | chance evas has of merging draw commands that have the same modes, | ||
242 | texture source etc., but the more overhead there is in finding a | ||
243 | pipeline slot for the draw command to merge into, so there is a | ||
244 | compromise here between spare cpu resources and gpu pipelining. unset | ||
245 | this environment variable to let evas use it's default value. | ||
246 | |||
247 | export EVAS_GL_ATLAS_ALLOC_SIZE=N | ||
248 | set the size (width in pixels) of the evas texture atlas strips that | ||
249 | are allocated. the default is 1024. unset this to let evas use its | ||
250 | default. if this value is larger than the maximum texture size, then it | ||
251 | is limited to that maximum size internally anyway. evas tries to | ||
252 | store images together in "atlases". these are large single textures | ||
253 | that contain multiple images within the same texture. to do this evas | ||
254 | allocates a "wide strip" of pixels (that is a certain height) and then | ||
255 | tries to fit all images loaded that need textures into an existing | ||
256 | atlas texture before allocating a new one. evas tries a best fit | ||
257 | policy to avoid too much wasting of texture memory. texture atlas | ||
258 | textures are always allocated to be EVAS_GL_ATLAS_ALLOC_SIZE width, | ||
259 | and a multiple of EVAS_GL_ATLAS_SLOT_SIZE pixels high (if possible - | ||
260 | power of 2 limits are enforced if required). | ||
261 | |||
262 | export EVAS_GL_ATLAS_ALLOC_ALPHA_SIZE=N | ||
263 | this is exactly the same as EVAS_GL_ATLAS_ALLOC_SIZE, but for | ||
264 | "alpha" textures (texture used for font glyph data). it works exactly | ||
265 | the same way as for images, but per font glyph being put in an atlas | ||
266 | slot. the default value for this is 4096. | ||
267 | |||
268 | export EVAS_GL_ATLAS_MAX_W=N | ||
269 | set this to limit the maximum image size (width) that will be | ||
270 | allowed to go into a texture atlas. if an image exceeds this size, it | ||
271 | gets allocated its own separate individual texture (this is to help | ||
272 | minimize fragmentation). the default value for this is 512. if you set | ||
273 | this environment variable it will be overridden by the value it is set | ||
274 | to. the maximum value possible here is 512. you may set it to a | ||
275 | smaller value. | ||
276 | |||
277 | export EVAS_GL_ATLAS_MAX_H=N | ||
278 | this is the same as EVAS_GL_ATLAS_MAX_W, but sets the maximum height | ||
279 | of an image that is allowed into an atlas texture. | ||
280 | |||
281 | export EVAS_GL_ATLAS_SLOT_SIZE=N | ||
282 | this sets the height granularity for atlas strips. the default (and | ||
283 | minimum) value is 16. this means texture atlas strips are always a | ||
284 | multiple of 16 pixels high (16, 32, 48, 64, etc...). this allows you | ||
285 | to change the granularity to another value to avoid having more | ||
286 | textures allocated or try and consolidate allocations into fewer atlas | ||
287 | strips etc. | ||
288 | |||
289 | export EVAS_GL_NO_MAP_IMAGE_SEC=1 | ||
290 | if this environment variable is set, it disabled support for the SEC | ||
291 | map image extension (a zero copy direct-texture access extension that | ||
292 | removes texture upload overhead). if you have problems with dynamic | ||
293 | evas images, and this is detected by evas (see EVAS_GL_INFO above to | ||
294 | find out if its detected), then setting this will allow it to be | ||
295 | forcibly disabled. unset it to allow auto-detection to keep working. | ||
296 | |||
297 | |||
298 | --enable-gl-flavor-gles | ||
299 | |||
300 | this enables the opengl-es 2.0 flavor of opengl (as opposed to desktop | ||
301 | opengl) when building evas's gl-x11 engine above. this will be needed | ||
302 | if you are building evas for opengl-es 2.0 enabled embedded devices. | ||
303 | evas works on several opengl-es 2.0 compliant gpu's and gains more | ||
304 | testing and optimization regularly. it is also capable of | ||
305 | texture-from-pixmap support in opengl-es like it is in desktop opengl. | ||
306 | |||
307 | |||
308 | --enable-gles-variety-sgx | ||
309 | |||
310 | this tells evas that you are building the gl-es engine for a | ||
311 | shader-compiler "sgx style" opengl-es 2.0 implementation. this is | ||
312 | where the shader compiler is provided at runtime and can accept the | ||
313 | shader glsl source and work | ||
314 | |||
315 | |||
316 | --enable-gles-variety-s3c6410 | ||
317 | |||
318 | this tells evas that you have an s3c6410 style opengl-es | ||
319 | implementation that has an offline shader compiler and that needs | ||
320 | pre-compiled shader binaries (provided with evas). this has not been | ||
321 | tested in quite a while as the drivers and environment for this system | ||
322 | have gone missing | ||
323 | |||
324 | |||
325 | --enable-software-gdi[=static] | ||
326 | |||
327 | windows gdi based engine for evas | ||
328 | |||
329 | |||
330 | --enable-software-ddraw[=static] | ||
331 | |||
332 | windows direct-draw engine for evas | ||
333 | |||
334 | |||
335 | --enable-direct3d[=static] | ||
336 | |||
337 | evas direct3d engine (experimental) | ||
338 | |||
339 | |||
340 | --enable-software-sdl[=static] | ||
341 | |||
342 | this is the sdl engine that uses sdl library (http://www.libsdl.org). This | ||
343 | library should work on many operating system. the buffer is | ||
344 | software-rendered with evas's default software rendering core. | ||
345 | |||
346 | |||
347 | --enable-gl-sdl[=static] | ||
348 | |||
349 | opengl (and opengl-es2.0) rendering engine that uses sdl as the front | ||
350 | end interface. see --enable-gl-x11 etc. for information. | ||
351 | |||
352 | |||
353 | --enable-software-8-x11[=static] | ||
354 | |||
355 | 8bit only rendering core. intended for greyscale output on things like | ||
356 | e-paper or simplistic greyscale LCD devices which have no color, such | ||
357 | as ebook readers. | ||
358 | |||
359 | if compiling with =static suffix, then must | ||
360 | "./configure --enable-static-software-8" as well. | ||
361 | |||
362 | |||
363 | --enable-software-16-x11[=static] | ||
364 | |||
365 | 16bit specific renderer. lower quality than the default. also limited | ||
366 | in abilities (no support for smooth scale or transformations/map). in | ||
367 | a state of disrepair. do not use unless your hardware is just 16bpp | ||
368 | and very limited in CPU and memory. | ||
369 | |||
370 | if compiling with =static suffix, then must | ||
371 | "./configure --enable-static-software-16" as well. | ||
372 | |||
373 | |||
374 | --enable-software-16-ddraw[=static] | ||
375 | |||
376 | 16bit renderer for direct-draw. same as software-16-x11 - don't use. | ||
377 | in disrepair. | ||
378 | |||
379 | if compiling with =static suffix, then must | ||
380 | "./configure --enable-static-software-16" as well. | ||
381 | |||
382 | |||
383 | --enable-software-16-wince[=static] | ||
384 | |||
385 | same as software-16-ddraw but for windows-ce. in disrepair. don't use. | ||
386 | |||
387 | if compiling with =static suffix, then must | ||
388 | "./configure --enable-static-software-16" as well. | ||
389 | |||
390 | |||
391 | ------------------------------------------------------------------------------ | ||
392 | CPU: | ||
393 | --enable-cpu-c | ||
394 | |||
395 | this enabled the c code. you can actually build the code without the c | ||
396 | fallback code and only have the mmx routines for example. it is suggested to | ||
397 | always use this regardless unless you have some definite size issues with the | ||
398 | code. | ||
399 | |||
400 | |||
401 | --enable-cpu-mmx | ||
402 | |||
403 | this enables the mmx optimized routines. this works for pentium, pentium2, | ||
404 | pentium3, pentium4, athlon and duron processors. it can get quite | ||
405 | considerable speedups, souse it if you can. ppc owners just have to live with | ||
406 | the c fallback functions unfortunately as no one has provided any ALTIVEC asm | ||
407 | routines yet. :) arm owners will also have to rely on the c fallback | ||
408 | routines as i haven't managed to come up with any arm assembly that actually | ||
409 | can beat the c code (when compiled with all optimizations) in speed. | ||
410 | |||
411 | |||
412 | --enable-cpu-sse | ||
413 | |||
414 | this enables sse optimizations available in he pentium3 and 4 cpus (not | ||
415 | athlon and duron or pentium 2 or pentium cpu's). ppc owners just have to | ||
416 | live with the c fallback functions unfortunately as no one has provided any | ||
417 | ALTIVEC asm routines yet. :) arm owners will also have to rely on the c | ||
418 | fallback routines as i haven't managed to come up with any arm assembly that | ||
419 | actually can beat the c code (when compiled with all optimizations) in speed. | ||
420 | |||
421 | --enable-cpu-sse3 | ||
422 | |||
423 | this enables sse3 optimizations available in the Intel Pentium4, Core, Xeon, | ||
424 | and Atom processors, as well as the AMD Athlon64, Phenom, Opteron, and Turion | ||
425 | processors. | ||
426 | |||
427 | |||
428 | --enable-cpu-neon | ||
429 | |||
430 | This enables support for the Arm Cortex-A8 and later Neon register | ||
431 | set. In particular it will use neon optimized code for rotations and | ||
432 | drawing with the software engines. Open GL based renderers will gain | ||
433 | nothing from the use of neon. | ||
434 | |||
435 | To use neon with gcc-4.4 you need a post-2009 gcc and options | ||
436 | something like: -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon | ||
437 | Note that this slightly slows down non-optimized parts of evas but | ||
438 | the gains in drawing are more then worth it overall. | ||
439 | |||
440 | This is enabled by default, and turns off if a small test program is | ||
441 | unable to compile. | ||
442 | |||
443 | Performance is at least 50%, and in some real world tests approaches | ||
444 | 100%. | ||
445 | |||
446 | If you have any issues with neon, please report them to either the | ||
447 | edevel mailing list or Brett Nash <nash@nash.id.au> | ||
448 | |||
449 | |||
450 | ------------------------------------------------------------------------------ | ||
451 | IMAGE LOADERS: | ||
452 | --enable-image-loader-png[=static] | ||
453 | |||
454 | this enables the loader code that loads png files using libpng. there may be | ||
455 | call for embedded devices later that have custom written small image | ||
456 | loaders that uses less disk space than libpng to load custom format images. | ||
457 | for now this is the only loader so you may as well include it. | ||
458 | |||
459 | |||
460 | --enable-image-loader-jpeg[=static] | ||
461 | |||
462 | this enables the loader code that loads jpeg files using libjpeg. this | ||
463 | loader also supports load options to pre-scale jpeg images down to | ||
464 | provide much faster load times while also getting downscaling by 1/2, | ||
465 | 1/4 or 1/8th the size in each dimension for "free". with an added | ||
466 | patch to libjpeg7, it can also fast-decode a specific region of a jpeg | ||
467 | file (without the patch it take a slow-path to do this). | ||
468 | |||
469 | |||
470 | --enable-image-loader-edb[=static] | ||
471 | |||
472 | edb image loader- can load images inside edb database files. not very | ||
473 | useful as edb itself is no longer used by enlightenment. may be | ||
474 | removed at some point, so unless you have a burning need for this, | ||
475 | don't use edb files to store image data and rely on this loader | ||
476 | |||
477 | |||
478 | --enable-image-loader-eet[=static] | ||
479 | |||
480 | loads image data from eet files. eet files are the backing for edje | ||
481 | storage, so this is needed for edje to work. it is very useful as it | ||
482 | can load an image from anywhere in the eet archive by key value so eet | ||
483 | files are like "zip" files where you can pack a whole lot of image and | ||
484 | other data together and just pick out the pieces you need at runtime. | ||
485 | requires the eet library. | ||
486 | |||
487 | |||
488 | --enable-image-loader-gif[=static] | ||
489 | |||
490 | gif image loader. gif is an obsolete format, but due to its longevity, | ||
491 | sitll has lots of existing data around. | ||
492 | |||
493 | NOTE: evas has no notion of time, thus animated gif file are not | ||
494 | supported! | ||
495 | |||
496 | |||
497 | --enable-image-loader-pmaps[=static] | ||
498 | |||
499 | ppm/pnm/pgm image loader that can load the "pnm" style image format. | ||
500 | not very common, but the files are simple raw RGB, greyscale image or | ||
501 | bitmap data in binary or ascii format | ||
502 | |||
503 | |||
504 | --enable-image-loader-svg[=static] | ||
505 | |||
506 | this loader can load svg files via librsvg (thus it is a dependency). | ||
507 | this loader supports load options to set the dpi to decode the svg at | ||
508 | etc. which can then be used to create scalable images that scale to | ||
509 | any size without becoming blocky or blurry, if the source is an svg | ||
510 | file. | ||
511 | |||
512 | |||
513 | --enable-image-loader-tiff[=static] | ||
514 | |||
515 | this loader uses libtiff to load tiff image files | ||
516 | |||
517 | |||
518 | --enable-image-loader-xpm[=static] | ||
519 | |||
520 | this is an xpm format image loader. xpm format images are ascii files | ||
521 | that look like c/c++ source code that contain images. these files are | ||
522 | old-fashioned unix+x11 images you may encounter, but are inefficient | ||
523 | for storage and decoding and have been superseded by png files in | ||
524 | almost every way | ||
525 | |||
526 | |||
527 | --enable-image-loader-bmp[=static] | ||
528 | |||
529 | this enables the bmp image format loader. note that there seems to be | ||
530 | a disagreement on 32bit bmp format images where alpha channels are | ||
531 | concerned and you may run into issues with bmps generated by the gimp | ||
532 | that have alpha channels. there is a problem where they don't seem to | ||
533 | be spec-conformant. | ||
534 | |||
535 | |||
536 | --enable-image-loader-tga[=static] | ||
537 | |||
538 | this loader load tga format files. these files are very old-fashioned | ||
539 | but found often in the 3d graphics world. | ||
540 | |||
541 | |||
542 | ------------------------------------------------------------------------------ | ||
543 | FONT LOADERS: | ||
544 | --enable-font-loader-eet[=static] | ||
545 | |||
546 | this loader can load font (ttf) files directly from eet archives like | ||
547 | the eet image loader. requires the eet library | ||
548 | |||
549 | |||
550 | ------------------------------------------------------------------------------ | ||
551 | CONVERTERS: | ||
552 | --enable-convert-yuv | ||
553 | |||
554 | this enables an optimized yuv (yv12 601 colorspace) to ARGB32 | ||
555 | converter in evas | ||
556 | |||
557 | |||
558 | --enable-convert-16-rgb-565 | ||
559 | |||
560 | the most common converter you'll want for 16bpp. this means 5 bits for red, | ||
561 | 6 bits for green and 5 bits for blue are used. | ||
562 | |||
563 | |||
564 | --enable-convert-16-rgb-555 | ||
565 | |||
566 | this is a converter for what many people know as "15 bit" color. you might | ||
567 | want to enable this for X output as it used to be common to find many cards | ||
568 | that do this. | ||
569 | |||
570 | |||
571 | --enable-convert-16-rgb-444 | ||
572 | |||
573 | this converter outputs to 12bit packed (int 16 bit WORDS). | ||
574 | |||
575 | |||
576 | --enable-convert-16-rgb-ipq | ||
577 | |||
578 | this converter was written specifically for the ipaq (and may apply to | ||
579 | similarly configured devices) because it lies about its screen depth. it | ||
580 | says it is 16bit 565 (that means 5 upper bits of the WORD are red, the next 6 | ||
581 | bits are for green abd the next 5 for blue) but in fact only the upper 4 | ||
582 | bits of each color component (red green and blue) are significant and work, | ||
583 | so effectively the display is 12 bits of color, not 16, but padded out to | ||
584 | fill 16bits, with unused bits in the color masks. X on the ipaq advertises | ||
585 | it as a full 16bpp 565 display (i can't remember what the linux framebuffer | ||
586 | advertised it as) and so many lumps of code can be fooled into rendering | ||
587 | data badly because they think the output will look as the expect. This | ||
588 | renderer assumes the upper 4 bits fo each color primitive only are | ||
589 | significant and renders accordingly. this produces nice quality images on | ||
590 | the ipaq and even still works in 16bpp 565 on your pc. it is highly | ||
591 | recommended to use this renderer if your target is an ipaq or your device | ||
592 | displays similar qualities of the ipaq for display purposes. | ||
593 | |||
594 | |||
595 | --enable-convert-16-rgb-rot-0 | ||
596 | |||
597 | this enables the 16bpp converters to run with 0 degrees rotation - this is | ||
598 | normal display and you should really include this (though it is optional if you | ||
599 | only ever want to do portrait mode - perhaps like on an ipaq embedded device) | ||
600 | |||
601 | |||
602 | --enable-convert-16-rgb-rot-270 | ||
603 | |||
604 | this enables the portrait mode (270 degree rotation) converters for 16bpp. | ||
605 | this is the standard display mode for things like pocketpc on the ipaq and | ||
606 | the zaurus etc. this is an optimized part of the rendering pipeline to allow | ||
607 | portrait display with a much lower overhead than doing it through X. | ||
608 | |||
609 | |||
610 | --enable-convert-16-rgb-rot-180 | ||
611 | |||
612 | same as --enable-convert-16-rgb-rot-270 but for 180 degrees | ||
613 | |||
614 | |||
615 | --enable-convert-16-rgb-rot-90 | ||
616 | |||
617 | same as --enable-convert-16-rgb-rot-270 but for 90 degrees | ||
618 | |||
619 | |||
620 | --enable-convert-24-rgb-888 | ||
621 | |||
622 | this converts evas's 32bit ARGB to 24bit RGB packed format for output | ||
623 | if needed | ||
624 | |||
625 | |||
626 | --enable-convert-24-bgr-888 | ||
627 | |||
628 | this converts evas's 32bit ARGB to 24bit packed BGR format for output | ||
629 | if needed | ||
630 | |||
631 | |||
632 | --enable-convert-32-rgb-8888 | ||
633 | |||
634 | 32bit RGB output conversion support. byteswapping compared to evas's | ||
635 | native colorspace | ||
636 | |||
637 | |||
638 | --enable-convert-32-bgr-8888 | ||
639 | |||
640 | conversion (reduces toa memory copy) from evas's native colorspace to | ||
641 | the same color format. | ||
642 | |||
643 | |||
644 | --enable-convert-32-rgb-rot-0 | ||
645 | |||
646 | copies without rotation evas's native image format | ||
647 | |||
648 | |||
649 | --enable-convert-32-rgb-rot-270 | ||
650 | |||
651 | copies evas's native ARGB32 pixels but at a rotation of 270 degrees. | ||
652 | |||
653 | |||
654 | --enable-convert-32-rgb-rot-180 | ||
655 | |||
656 | same as --enable-convert-32-rgb-rot-270 but for 180 degrees | ||
657 | |||
658 | |||
659 | --enable-convert-32-rgb-rot-90 | ||
660 | |||
661 | same as --enable-convert-32-rgb-rot-270 but for 90 degrees | ||
662 | |||
663 | |||
664 | --enable-convert-24-rgb-ezx | ||
665 | |||
666 | a special colorspace handler for 18bit color packed into 24bit output | ||
667 | (where only 6 bits per r, g and b byte are used). the only known | ||
668 | platform that did this was the motorola esx based phones that used | ||
669 | qtopia originally and have open ezx ports for them. | ||
670 | |||
671 | |||
672 | --enable-convert-8-gry-1 | ||
673 | |||
674 | enable 8bit gray to 1 bit black & white converter | ||
675 | |||
676 | |||
677 | --enable-convert-8-gry-16 | ||
678 | |||
679 | 8bit grey to 16 level grayscale converter | ||
680 | |||
681 | |||
682 | --enable-convert-8-grayscale-64 | ||
683 | |||
684 | 8bit grey to 64 level grayscale converter | ||
685 | |||
686 | |||
687 | --enable-convert-8-rgb-332 | ||
688 | |||
689 | enable converter from 32bit ARGB to 8bit color "332" colorspace (3bits | ||
690 | red, 3 bits green, 2 bits blue) | ||
691 | |||
692 | |||
693 | --enable-convert-8-rgb-666 | ||
694 | |||
695 | enable converter from 32bit ARGB to 8bit color "216" "websafe" | ||
696 | colorspace (6 values for red, 6 for green and 6 for blue - 6x6x6 being | ||
697 | 216 colors). | ||
698 | |||
699 | |||
700 | --enable-convert-8-rgb-232 | ||
701 | |||
702 | same as convert-8-rgb-332 but 2 bits red, 3 green, 2 blue | ||
703 | |||
704 | |||
705 | --enable-convert-8-rgb-222 | ||
706 | |||
707 | same as convert-8-rgb-332 but 2 bits red, 2 green, 2 blue | ||
708 | |||
709 | |||
710 | --enable-convert-8-rgb-221 | ||
711 | |||
712 | same as convert-8-rgb-332 but 2 bits red, 2 green, 1 blue | ||
713 | |||
714 | |||
715 | --enable-convert-8-rgb-121 | ||
716 | |||
717 | same as convert-8-rgb-332 but 1 bit red, 2 green, 1 blue | ||
718 | |||
719 | |||
720 | --enable-convert-8-rgb-111 | ||
721 | |||
722 | same as convert-8-rgb-332 but 1 bit red, 1 green, 1 blue. this is the | ||
723 | lowest sized colorspace supported for rgb (3bits, 8 color). | ||
724 | |||
725 | |||
726 | ------------------------------------------------------------------------------ | ||
727 | MISC: | ||
728 | --enable-pthreads | ||
729 | |||
730 | this enables pthread support in evas so multiple threads may run | ||
731 | internally for parallel rendering, loading etc. | ||
732 | |||
733 | |||
734 | --enable-async-events | ||
735 | |||
736 | this provides the ability for evas to have an asynchronous event | ||
737 | notification pipe to provide events when background threads are done | ||
738 | with tasks, like pre-loading image files | ||
739 | |||
740 | |||
741 | --enable-async-preload | ||
742 | |||
743 | evas can load images (preload) them in the background using a thread | ||
744 | if you ask it to, and provide events when done. this goes hand-in-hand | ||
745 | with --enable-pthreads and --enable-async-events. you really want all | ||
746 | of these available. | ||
747 | |||
748 | |||
749 | --enable-async-render **CAUTION - MAY NOT WORK RIGHT** | ||
750 | |||
751 | this enables a software multi-frame threaded renderer. this will | ||
752 | allocate (for example) 2 frames to 2 cores, with one core of the cpu | ||
753 | rendering the previous frame while the next frame starts rendering on | ||
754 | another core in the meantime allowing for higher framerates with | ||
755 | software rendering, using more cpu resources that are available on | ||
756 | modern multi-core cpu's. | ||
757 | |||
758 | This is buggy! it will likely cause crashes and rendering corruption. | ||
759 | Do not enable it unless you plan to actually work on it. This requires you | ||
760 | also set the environment variable EVAS_RENDER_MODE to "non-blocking" to | ||
761 | enable it at runtime, as the compile-time enable simply sets up the feature | ||
762 | to be ready to work. The runtime switch actually turns it on. If you don't | ||
763 | plan to use this feature, don't enable it in the build as there is a general | ||
764 | performance hit of maintaining this feature at all, so beware that | ||
765 | enabling it for single core systems will likely take a performance hit. | ||
766 | |||
767 | |||
768 | --enable-pipe-render **DISABLED DUE TO BUGS** | ||
769 | |||
770 | this enables a multiple-thread renderer that divides the rendering | ||
771 | into N regions (1 per core) to speed up rendering in software when you | ||
772 | have multiple cpu cores. | ||
773 | |||
774 | |||
775 | --enable-word-cache **DISABLED DUE TO BUGS** | ||
776 | |||
777 | Cache rendered words and draw them as a single object, instead of | ||
778 | individual characters. This is a big gain for things like neon which | ||
779 | draw large runs effectively. | ||
780 | |||
781 | However it is useless on GL and similar back-ends as the cost in | ||
782 | sending a word sized texture kills the performance gain (and GL is | ||
783 | pretty good at drawing lots of small things anyway). If it detects a GL | ||
784 | backend is in use, it disables itself. | ||
785 | |||
786 | By default words (strings) of more then 50 characters are not cached. | ||
787 | The system caches 40 words by default, but this can be changed by | ||
788 | setting EVAS_WORD_CACHE_MAX_WORDS to another number. Setting it to 0 | ||
789 | will disable word-cache at run time. | ||
790 | |||
791 | Text based benchmarks are 50-100% quicker. | ||
792 | |||
793 | If you have any issues with word caching, please report them to either | ||
794 | the e-devel mailing list or Brett Nash <nash@nash.id.uau> | ||
795 | |||
796 | For GL see metric caching... | ||
797 | |||
798 | |||
799 | --enable-metric-cache **DISABLED DUE TO BUGS** | ||
800 | |||
801 | Metric caching saves character metrics between characters in words. | ||
802 | This enables it to render words much quicker as it avoids things like | ||
803 | space calculations and kerning calculation. | ||
804 | |||
805 | The cache size is also controlled by EVAS_WORD_CACHE_MAX_WORDS. | ||
806 | |||
807 | It is useful for GL in particular, although software engines do get | ||
808 | some gain. | ||
809 | |||
810 | Generally it is recommended you enable one or both of word or metric caching, | ||
811 | depending on your engine use. If you are only using software, enable word | ||
812 | caching (and neon on arm if you can), for GL, turn on metric caching. | ||
813 | A simple solution is enable both, and let the engine sort it out at run time. | ||
814 | |||
815 | If you have any issues with metric caching, please report them to either | ||
816 | the e-devel mailing list or Brett Nash <nash@nash.id.uau> | ||
817 | |||
818 | |||
819 | --enable-fontconfig | ||
820 | |||
821 | this enables fontconfig support for loading font files by using | ||
822 | generic fontconfig font names and styles. you really should use this | ||
823 | by default on any linux/unix platform for universal font support. | ||
824 | |||
825 | |||
826 | --enable-fribidi | ||
827 | |||
828 | this enables support for the fribidi library to have right to left and | ||
829 | left to right font rendering so languges such as arabic, hebrew and | ||
830 | other "RTL" langauges display properly. | ||
831 | |||
832 | |||
833 | --enable-harfbuzz | ||
834 | |||
835 | this enables support for the harfbuzz shaping library for complex | ||
836 | shaping support in arabic, hindi and other similar languages. | ||
837 | |||
838 | --enable-liblinebreak | ||
839 | |||
840 | this enables support of complex line breaking rules using liblinebreak. | ||
841 | |||
842 | --enable-evas-magic-debug | ||
843 | |||
844 | this allows you to enable and disable evas's extra magic number | ||
845 | checks. these allow better stability with runtime object magic | ||
846 | "number" checks to make sure you are accessing a real object in memory | ||
847 | of the right type, and will avoid doing "bad things" if they detect | ||
848 | the wrong object type being passed in. if you are absolutely sure your | ||
849 | system has no bugs in accessing objects of the wrong type with the | ||
850 | wrong calls, you can gain some small performance by disabling this. | ||
851 | |||
852 | |||
853 | ------------------------------------------------------------------------------ | ||
854 | NOTES: | ||
855 | |||
856 | For the arm optimizations you want to try: | ||
857 | export CFLAGS="-O2 -march=armv5te -mcpu=arm1136jf-s -fomit-frame-pointer" | ||
858 | |||
859 | To enable the async renderer compile with: | ||
860 | --enable-async-render | ||
861 | and also runtime set this environment variable: | ||
862 | export EVAS_RENDER_MODE=non-blocking | ||
863 | |||
864 | For compilation with MinGW, fnmatch.h is probably missing. That file can be | ||
865 | found here: | ||
866 | http://www.koders.com/c/fid2B518462CB1EED3D4E31E271DB83CD1582F6EEBE.aspx | ||
867 | It should be installed in the mingw include directory. | ||
868 | |||