3 ******************************************************************************
5 FOR ANY ISSUES PLEASE EMAIL:
6 enlightenment-devel@lists.sourceforge.net
8 ******************************************************************************
16 eina (1.0.0 or better)
17 freetype (2.1.9 or better)
29 XCB SDL OpenGL librsvg libtiff libgif edb DirectFB
31 Evas is a clean display canvas API for several target display systems
32 that can draw anti-aliased text, smooth super and sub-sampled scaled
33 images, alpha-blend objects much and more.
35 Evas is designed to be portable to different display systems. Evas uses very
36 little RAM too (try profiling it in memprof if you want to
37 know) most of the ram allocated, if you look, is for freetype itself,
38 image pixel data, and font glyph data. You can't really avoid this, though
39 evas tries to share this data as much as possible and not duplicate where it
40 can. Feel free to point me at sensible memory optimizations etc. though :) I
41 want this baby to be lean, mean tiny, fast and do everything from your
42 massive multi-cpu desktop with gobs of ram and disk to a tiny watch.
44 Evas also supports full UTF-8 for text object strings, thus allowing for
45 full internationalized text strings (if your font gives you all the
46 characters). I've tested with quite a few fonts and it works quite well.
47 Though 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
49 only from left to right, so arabic, hebrew etc. won't display quite right,
50 direction-wise, but the characters do.
52 ------------------------------------------------------------------------------
53 COMPILING AND INSTALLING:
57 (as root unless you are installing in your users directories):
60 if you want to know what options to enable
63 Evas's rendering code assumes a decently optimizing compiler. For
64 example gcc with -O2 -march=nocona for example (compile for core2 duo
65 x86 or better). You may choose not to compile for a very modern
66 architecture, and Evas still has MMX/SSE, NEON and other hand-crafted
67 assembly, but not for everything, so make use of your compiler
68 optimizing as much as possible. At least use -O2 or equivalents.
71 the small dither mask is faster on the ipaq, but is not as good looking. on
72 desktop machines it makes no speed difference so only use
73 --enable-small-dither-mask if you are compiling for the ipaq
74 you need at least 1 image loader if you want to load images.
75 gcc 3.0.x on solaris screws up the jpeg code so erroring out doesn't work.
76 use gcc 3.2 on solaris.
78 notes on features (--enable-FEATURE enables it and --disable-FEATURE
79 disables it, some being enabled or disabled by default or if
80 dependencies are found):
83 ------------------------------------------------------------------------------
87 this enables the sampling scaler code. this is the fastest image scaling
88 code, but also the lowest quality. when scaling up pixels will become blocky
89 and when scaling down you will see shimmering/aliasing artifacts. this is a
90 speed vs. quality tradeoff
95 this is the nicest looking scaler that is not that much slower than
96 tri-linear, but it looks really good.
99 ------------------------------------------------------------------------------
101 --enable-small-dither-mask
103 this uses a 4x4 dither mask instead of 128x128. on desktop boxes these days
104 (pentium, pentium2, amd etc.) the speed difference is not really measurable,
105 but the quality of the 128x128 dither mask is quite a lot better. patterns
106 of dithering are much less noticeable, so it is recommended to not enable
107 this unless you are struggling for speed. the compaq ipaq for example shows
108 a slowdown with this large a dither mask so enabling a small dither mask is
109 recommended unless you really want to forgo the speed.
112 --enable-line-dither-mask
114 this is a faster alternative to the small or large dither masks above.
115 this dithers only on an alternating-line basis. this only provides 1
116 intermediate "dither" level whose odd and even pixels alternate
117 between the 2 closest colors available, but it is very fast. almost as
118 fast as no dithering. quality though will not be as good as small or
119 default "large" dither masks.
122 --enable-no-dither-mask
124 this disables dithering entirely. this is the fastest option, but the
125 lowest quality. not suggested in general unless you are really in need
126 of an extra few percent speed and are willing to have fairly awful
127 quality. but in general this is the standard rendering for most
128 "realtime graphics" if it has to drop to lower bit-depths, so it's
129 not anything unusual. just in the evas world the quality is considered
130 poor enough to be discouraged as evas's internal rendering is so much
134 ------------------------------------------------------------------------------
137 All engines can be compiled statically inside libevas.so in order to
138 reduce runtime time at dynamically loaded modules. All you have to do
139 is to enable your chosen modules with "=static" suffix. If they depend
140 on software_generic (most do), you need that as well. Examples:
142 ./configure --enable-static-software-generic --enable-software-xlib=static
145 --enable-software-xlib[=static]
147 this enables the software x11 rendering engine that renders to X drawable
148 targets using highly optimized software routines. there is no hardware
149 assist here. this engine requires X11 to be installed to build (and run).
150 This is a good generic engine that is fast and can run in X for good
151 development and debugging purposes.
154 --enable-software-xcb[=static]
156 this enable the software xcb rendering engine. It allows the same
157 features than the software xlib engine. It require the XCB and XCBImage
158 libraries. For the test programs, XCBICCCM is also needed. It is not
159 recommended to use this as it's experimental and will create problems
160 with both ecore_evas and enlightenment itself.
165 this is the software framebuffer driving engine. this uses the linux
166 framebuffer device (/dev/fb{X}) and will currently just inherit the current
167 framebuffer settings on the fb device and use them to run in. this engine is
168 almost fully functional except for the fb management itself. this engine is
169 specifically geared towards people writing minimalist display systems for
170 embedded devices such as the ipaq, zaurus, etc. it also scales up to high-res
175 --enable-directfb[=static]
177 this is the direct fb engine that uses direcftb (http://www.directfb.org) on
178 linux to access the framebuffer with (or maybe without) acceleration. for
179 people making set-top boxes or just wanting an alternative to X this is
180 really good. it may also be useful for embedded devices supported by
181 directfb that offer acceleration (otherwise the fb driver will likely be
182 faster). as such this engine is in relative disrepair and is not
183 maintained. use with great care.
186 --enable-buffer[=static]
188 this enables the memory buffer rendering engine. this engine renders
189 to a region of memory that is considered to be a 32bit ARGB buffer of
190 pixels, allowing the results of rendering to be directly read out or
191 used again for other purposes.
194 --enable-gl-x11[=static]
196 this is the opengl engine. it is intended for an x11 target (via xlib)
197 rather than framebuffer (even if you use EGL, the EGL flavor is
198 expected to be an x11 one). it is a full opengl based rendering engine
199 with all rendering implemented as a texture + triangle pipeline and
200 more. it also supports opengl-es2.0 and is reliant on modern opengl2.0+
201 shader support. this engine also supports the native surface api for
202 adopting pixmaps directly to textures for compositing.
204 some environment variables that control the opengl engine are as
207 export EVAS_GL_INFO=1
208 set this environment variable to enable output of opengl information
209 such as vendor, version, extensions, maximum texture size etc. unset
210 the environment variable to make the output quiet again.
212 export EVAS_GL_MEMINFO=1
213 set this environment variable to enable dumping of debug output
214 whenever textures are allocated or freed, giving the number of
215 textures of each time and how many kb worth of pixel data are
216 allocated for the textures. unset it again to stop this dumping of
219 export EVAS_GL_WIN_RESURF=1
220 set this environment variable to enable the gl engine to try and
221 ddelete the window surface, if it can, when told to "dump resources"
222 to save memory, and re-allocate it when needed (when rendering
223 occurs). unset it to not have this behavior.
225 export EVAS_GL_CUTOUT_MAX=N
226 set this environment variable to the maximum number of rectangles
227 applied to a rendering of a primitive that "cut away" parts of that
228 primitive to render to avoid overdraw. default is 512. unset it to use
229 defaults, otherwise set N to the max value desired or to -1 for
230 "unlimited rectangles".
232 export EVAS_GL_PIPES_MAX=N
233 set the maximum number of parallel pending pipelines to N. the
234 default number is 32 (except on tegra2 where is it 1). evas keeps 1 (or more)
235 pipelines of gl draw commands in parallel at any time, to allow for merging
236 of non-overlapping draw commands to avoid texture binding and context
237 changes which allows for more streamlining of the draw arrays that are
238 filled and passed to gl per frame. the more pipelines exist, the more
239 chance evas has of merging draw commands that have the same modes,
240 texture source etc., but the more overhead there is in finding a
241 pipeline slot for the draw command to merge into, so there is a
242 compromise here between spare cpu resources and gpu pipelining. unset
243 this environment variable to let evas use it's default value.
245 export EVAS_GL_ATLAS_ALLOC_SIZE=N
246 set the size (width in pixels) of the evas texture atlas strips that
247 are allocated. the default is 1024. unset this to let evas use its
248 default. if this value is larger than the maximum texture size, then it
249 is limited to that maximum size internally anyway. evas tries to
250 store images together in "atlases". these are large single textures
251 that contain multiple images within the same texture. to do this evas
252 allocates a "wide strip" of pixels (that is a certain height) and then
253 tries to fit all images loaded that need textures into an existing
254 atlas texture before allocating a new one. evas tries a best fit
255 policy to avoid too much wasting of texture memory. texture atlas
256 textures are always allocated to be EVAS_GL_ATLAS_ALLOC_SIZE width,
257 and a multiple of EVAS_GL_ATLAS_SLOT_SIZE pixels high (if possible -
258 power of 2 limits are enforced if required).
260 export EVAS_GL_ATLAS_ALLOC_ALPHA_SIZE=N
261 this is exactly the same as EVAS_GL_ATLAS_ALLOC_SIZE, but for
262 "alpha" textures (texture used for font glyph data). it works exactly
263 the same way as for images, but per font glyph being put in an atlas
264 slot. the default value for this is 4096.
266 export EVAS_GL_ATLAS_MAX_W=N
267 set this to limit the maximum image size (width) that will be
268 allowed to go into a texture atlas. if an image exceeds this size, it
269 gets allocated its own separate individual texture (this is to help
270 minimize fragmentation). the default value for this is 512. if you set
271 this environment variable it will be overridden by the value it is set
272 to. the maximum value possible here is 512. you may set it to a
275 export EVAS_GL_ATLAS_MAX_H=N
276 this is the same as EVAS_GL_ATLAS_MAX_W, but sets the maximum height
277 of an image that is allowed into an atlas texture.
279 export EVAS_GL_ATLAS_SLOT_SIZE=N
280 this sets the height granularity for atlas strips. the default (and
281 minimum) value is 16. this means texture atlas strips are always a
282 multiple of 16 pixels high (16, 32, 48, 64, etc...). this allows you
283 to change the granularity to another value to avoid having more
284 textures allocated or try and consolidate allocations into fewer atlas
287 export EVAS_GL_NO_MAP_IMAGE_SEC=1
288 if this environment variable is set, it disabled support for the SEC
289 map image extension (a zero copy direct-texture access extension that
290 removes texture upload overhead). if you have problems with dynamic
291 evas images, and this is detected by evas (see EVAS_GL_INFO above to
292 find out if its detected), then setting this will allow it to be
293 forcibly disabled. unset it to allow auto-detection to keep working.
296 --enable-gl-flavor-gles
298 this enables the opengl-es 2.0 flavor of opengl (as opposed to desktop
299 opengl) when building evas's gl-x11 engine above. this will be needed
300 if you are building evas for opengl-es 2.0 enabled embedded devices.
301 evas works on several opengl-es 2.0 compliant gpu's and gains more
302 testing and optimization regularly. it is also capable of
303 texture-from-pixmap support in opengl-es like it is in desktop opengl.
306 --enable-gles-variety-sgx
308 this tells evas that you are building the gl-es engine for a
309 shader-compiler "sgx style" opengl-es 2.0 implementation. this is
310 where the shader compiler is provided at runtime and can accept the
311 shader glsl source and work
314 --enable-gles-variety-s3c6410
316 this tells evas that you have an s3c6410 style opengl-es
317 implementation that has an offline shader compiler and that needs
318 pre-compiled shader binaries (provided with evas). this has not been
319 tested in quite a while as the drivers and environment for this system
323 --enable-software-gdi[=static]
325 windows gdi based engine for evas
328 --enable-software-ddraw[=static]
330 windows direct-draw engine for evas
333 --enable-direct3d[=static]
335 evas direct3d engine (experimental)
338 --enable-software-sdl[=static]
340 this is the sdl engine that uses sdl library (http://www.libsdl.org). This
341 library should work on many operating system. the buffer is
342 software-rendered with evas's default software rendering core.
345 --enable-gl-sdl[=static]
347 opengl (and opengl-es2.0) rendering engine that uses sdl as the front
348 end interface. see --enable-gl-x11 etc. for information.
351 --enable-software-8-x11[=static]
353 8bit only rendering core. intended for greyscale output on things like
354 e-paper or simplistic greyscale LCD devices which have no color, such
357 if compiling with =static suffix, then must
358 "./configure --enable-static-software-8" as well.
361 --enable-software-16-x11[=static]
363 16bit specific renderer. lower quality than the default. also limited
364 in abilities (no support for smooth scale or transformations/map). in
365 a state of disrepair. do not use unless your hardware is just 16bpp
366 and very limited in CPU and memory.
368 if compiling with =static suffix, then must
369 "./configure --enable-static-software-16" as well.
372 --enable-software-16-ddraw[=static]
374 16bit renderer for direct-draw. same as software-16-x11 - don't use.
377 if compiling with =static suffix, then must
378 "./configure --enable-static-software-16" as well.
381 --enable-software-16-wince[=static]
383 same as software-16-ddraw but for windows-ce. in disrepair. don't use.
385 if compiling with =static suffix, then must
386 "./configure --enable-static-software-16" as well.
389 ------------------------------------------------------------------------------
393 this enabled the c code. you can actually build the code without the c
394 fallback code and only have the mmx routines for example. it is suggested to
395 always use this regardless unless you have some definite size issues with the
401 this enables the mmx optimized routines. this works for pentium, pentium2,
402 pentium3, pentium4, athlon and duron processors. it can get quite
403 considerable speedups, souse it if you can. ppc owners just have to live with
404 the c fallback functions unfortunately as no one has provided any ALTIVEC asm
405 routines yet. :) arm owners will also have to rely on the c fallback
406 routines as i haven't managed to come up with any arm assembly that actually
407 can beat the c code (when compiled with all optimizations) in speed.
412 this enables sse optimizations available in he pentium3 and 4 cpus (not
413 athlon and duron or pentium 2 or pentium cpu's). ppc owners just have to
414 live with the c fallback functions unfortunately as no one has provided any
415 ALTIVEC asm routines yet. :) arm owners will also have to rely on the c
416 fallback routines as i haven't managed to come up with any arm assembly that
417 actually can beat the c code (when compiled with all optimizations) in speed.
421 this enables sse3 optimizations available in the Intel Pentium4, Core, Xeon,
422 and Atom processors, as well as the AMD Athlon64, Phenom, Opteron, and Turion
428 This enables support for the Arm Cortex-A8 and later Neon register
429 set. In particular it will use neon optimized code for rotations and
430 drawing with the software engines. Open GL based renderers will gain
431 nothing from the use of neon.
433 To use neon with gcc-4.4 you need a post-2009 gcc and options
434 something like: -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon
435 Note that this slightly slows down non-optimized parts of evas but
436 the gains in drawing are more then worth it overall.
438 This is enabled by default, and turns off if a small test program is
441 Performance is at least 50%, and in some real world tests approaches
444 If you have any issues with neon, please report them to either the
445 edevel mailing list or Brett Nash <nash@nash.id.au>
448 ------------------------------------------------------------------------------
450 --enable-image-loader-png[=static]
452 this enables the loader code that loads png files using libpng. there may be
453 call for embedded devices later that have custom written small image
454 loaders that uses less disk space than libpng to load custom format images.
455 for now this is the only loader so you may as well include it.
458 --enable-image-loader-jpeg[=static]
460 this enables the loader code that loads jpeg files using libjpeg. this
461 loader also supports load options to pre-scale jpeg images down to
462 provide much faster load times while also getting downscaling by 1/2,
463 1/4 or 1/8th the size in each dimension for "free". with an added
464 patch to libjpeg7, it can also fast-decode a specific region of a jpeg
465 file (without the patch it take a slow-path to do this).
468 --enable-image-loader-edb[=static]
470 edb image loader- can load images inside edb database files. not very
471 useful as edb itself is no longer used by enlightenment. may be
472 removed at some point, so unless you have a burning need for this,
473 don't use edb files to store image data and rely on this loader
476 --enable-image-loader-eet[=static]
478 loads image data from eet files. eet files are the backing for edje
479 storage, so this is needed for edje to work. it is very useful as it
480 can load an image from anywhere in the eet archive by key value so eet
481 files are like "zip" files where you can pack a whole lot of image and
482 other data together and just pick out the pieces you need at runtime.
483 requires the eet library.
486 --enable-image-loader-gif[=static]
488 gif image loader. gif is an obsolete format, but due to its longevity,
489 sitll has lots of existing data around.
491 NOTE: evas has no notion of time, thus animated gif file are not
495 --enable-image-loader-pmaps[=static]
497 ppm/pnm/pgm image loader that can load the "pnm" style image format.
498 not very common, but the files are simple raw RGB, greyscale image or
499 bitmap data in binary or ascii format
502 --enable-image-loader-svg[=static]
504 this loader can load svg files via librsvg (thus it is a dependency).
505 this loader supports load options to set the dpi to decode the svg at
506 etc. which can then be used to create scalable images that scale to
507 any size without becoming blocky or blurry, if the source is an svg
511 --enable-image-loader-tiff[=static]
513 this loader uses libtiff to load tiff image files
516 --enable-image-loader-xpm[=static]
518 this is an xpm format image loader. xpm format images are ascii files
519 that look like c/c++ source code that contain images. these files are
520 old-fashioned unix+x11 images you may encounter, but are inefficient
521 for storage and decoding and have been superseded by png files in
525 --enable-image-loader-bmp[=static]
527 this enables the bmp image format loader. note that there seems to be
528 a disagreement on 32bit bmp format images where alpha channels are
529 concerned and you may run into issues with bmps generated by the gimp
530 that have alpha channels. there is a problem where they don't seem to
534 --enable-image-loader-tga[=static]
536 this loader load tga format files. these files are very old-fashioned
537 but found often in the 3d graphics world.
540 ------------------------------------------------------------------------------
542 --enable-font-loader-eet[=static]
544 this loader can load font (ttf) files directly from eet archives like
545 the eet image loader. requires the eet library
548 ------------------------------------------------------------------------------
552 this enables an optimized yuv (yv12 601 colorspace) to ARGB32
556 --enable-convert-16-rgb-565
558 the most common converter you'll want for 16bpp. this means 5 bits for red,
559 6 bits for green and 5 bits for blue are used.
562 --enable-convert-16-rgb-555
564 this is a converter for what many people know as "15 bit" color. you might
565 want to enable this for X output as it used to be common to find many cards
569 --enable-convert-16-rgb-444
571 this converter outputs to 12bit packed (int 16 bit WORDS).
574 --enable-convert-16-rgb-ipq
576 this converter was written specifically for the ipaq (and may apply to
577 similarly configured devices) because it lies about its screen depth. it
578 says it is 16bit 565 (that means 5 upper bits of the WORD are red, the next 6
579 bits are for green abd the next 5 for blue) but in fact only the upper 4
580 bits of each color component (red green and blue) are significant and work,
581 so effectively the display is 12 bits of color, not 16, but padded out to
582 fill 16bits, with unused bits in the color masks. X on the ipaq advertises
583 it as a full 16bpp 565 display (i can't remember what the linux framebuffer
584 advertised it as) and so many lumps of code can be fooled into rendering
585 data badly because they think the output will look as the expect. This
586 renderer assumes the upper 4 bits fo each color primitive only are
587 significant and renders accordingly. this produces nice quality images on
588 the ipaq and even still works in 16bpp 565 on your pc. it is highly
589 recommended to use this renderer if your target is an ipaq or your device
590 displays similar qualities of the ipaq for display purposes.
593 --enable-convert-16-rgb-rot-0
595 this enables the 16bpp converters to run with 0 degrees rotation - this is
596 normal display and you should really include this (though it is optional if you
597 only ever want to do portrait mode - perhaps like on an ipaq embedded device)
600 --enable-convert-16-rgb-rot-270
602 this enables the portrait mode (270 degree rotation) converters for 16bpp.
603 this is the standard display mode for things like pocketpc on the ipaq and
604 the zaurus etc. this is an optimized part of the rendering pipeline to allow
605 portrait display with a much lower overhead than doing it through X.
608 --enable-convert-16-rgb-rot-180
610 same as --enable-convert-16-rgb-rot-270 but for 180 degrees
613 --enable-convert-16-rgb-rot-90
615 same as --enable-convert-16-rgb-rot-270 but for 90 degrees
618 --enable-convert-24-rgb-888
620 this converts evas's 32bit ARGB to 24bit RGB packed format for output
624 --enable-convert-24-bgr-888
626 this converts evas's 32bit ARGB to 24bit packed BGR format for output
630 --enable-convert-32-rgb-8888
632 32bit RGB output conversion support. byteswapping compared to evas's
636 --enable-convert-32-bgr-8888
638 conversion (reduces toa memory copy) from evas's native colorspace to
639 the same color format.
642 --enable-convert-32-rgb-rot-0
644 copies without rotation evas's native image format
647 --enable-convert-32-rgb-rot-270
649 copies evas's native ARGB32 pixels but at a rotation of 270 degrees.
652 --enable-convert-32-rgb-rot-180
654 same as --enable-convert-32-rgb-rot-270 but for 180 degrees
657 --enable-convert-32-rgb-rot-90
659 same as --enable-convert-32-rgb-rot-270 but for 90 degrees
662 --enable-convert-24-rgb-ezx
664 a special colorspace handler for 18bit color packed into 24bit output
665 (where only 6 bits per r, g and b byte are used). the only known
666 platform that did this was the motorola esx based phones that used
667 qtopia originally and have open ezx ports for them.
670 --enable-convert-8-gry-1
672 enable 8bit gray to 1 bit black & white converter
675 --enable-convert-8-gry-16
677 8bit grey to 16 level grayscale converter
680 --enable-convert-8-grayscale-64
682 8bit grey to 64 level grayscale converter
685 --enable-convert-8-rgb-332
687 enable converter from 32bit ARGB to 8bit color "332" colorspace (3bits
688 red, 3 bits green, 2 bits blue)
691 --enable-convert-8-rgb-666
693 enable converter from 32bit ARGB to 8bit color "216" "websafe"
694 colorspace (6 values for red, 6 for green and 6 for blue - 6x6x6 being
698 --enable-convert-8-rgb-232
700 same as convert-8-rgb-332 but 2 bits red, 3 green, 2 blue
703 --enable-convert-8-rgb-222
705 same as convert-8-rgb-332 but 2 bits red, 2 green, 2 blue
708 --enable-convert-8-rgb-221
710 same as convert-8-rgb-332 but 2 bits red, 2 green, 1 blue
713 --enable-convert-8-rgb-121
715 same as convert-8-rgb-332 but 1 bit red, 2 green, 1 blue
718 --enable-convert-8-rgb-111
720 same as convert-8-rgb-332 but 1 bit red, 1 green, 1 blue. this is the
721 lowest sized colorspace supported for rgb (3bits, 8 color).
724 ------------------------------------------------------------------------------
728 this enables pthread support in evas so multiple threads may run
729 internally for parallel rendering, loading etc.
732 --enable-async-events
734 this provides the ability for evas to have an asynchronous event
735 notification pipe to provide events when background threads are done
736 with tasks, like pre-loading image files
739 --enable-async-preload
741 evas can load images (preload) them in the background using a thread
742 if you ask it to, and provide events when done. this goes hand-in-hand
743 with --enable-pthreads and --enable-async-events. you really want all
747 --enable-async-render **CAUTION - MAY NOT WORK RIGHT**
749 this enables a software multi-frame threaded renderer. this will
750 allocate (for example) 2 frames to 2 cores, with one core of the cpu
751 rendering the previous frame while the next frame starts rendering on
752 another core in the meantime allowing for higher framerates with
753 software rendering, using more cpu resources that are available on
754 modern multi-core cpu's.
756 This is buggy! it will likely cause crashes and rendering corruption.
757 Do not enable it unless you plan to actually work on it. This requires you
758 also set the environment variable EVAS_RENDER_MODE to "non-blocking" to
759 enable it at runtime, as the compile-time enable simply sets up the feature
760 to be ready to work. The runtime switch actually turns it on. If you don't
761 plan to use this feature, don't enable it in the build as there is a general
762 performance hit of maintaining this feature at all, so beware that
763 enabling it for single core systems will likely take a performance hit.
766 --enable-pipe-render **DISABLED DUE TO BUGS**
768 this enables a multiple-thread renderer that divides the rendering
769 into N regions (1 per core) to speed up rendering in software when you
770 have multiple cpu cores.
773 --enable-word-cache **DISABLED DUE TO BUGS**
775 Cache rendered words and draw them as a single object, instead of
776 individual characters. This is a big gain for things like neon which
777 draw large runs effectively.
779 However it is useless on GL and similar back-ends as the cost in
780 sending a word sized texture kills the performance gain (and GL is
781 pretty good at drawing lots of small things anyway). If it detects a GL
782 backend is in use, it disables itself.
784 By default words (strings) of more then 50 characters are not cached.
785 The system caches 40 words by default, but this can be changed by
786 setting EVAS_WORD_CACHE_MAX_WORDS to another number. Setting it to 0
787 will disable word-cache at run time.
789 Text based benchmarks are 50-100% quicker.
791 If you have any issues with word caching, please report them to either
792 the e-devel mailing list or Brett Nash <nash@nash.id.uau>
794 For GL see metric caching...
797 --enable-metric-cache **DISABLED DUE TO BUGS**
799 Metric caching saves character metrics between characters in words.
800 This enables it to render words much quicker as it avoids things like
801 space calculations and kerning calculation.
803 The cache size is also controlled by EVAS_WORD_CACHE_MAX_WORDS.
805 It is useful for GL in particular, although software engines do get
808 Generally it is recommended you enable one or both of word or metric caching,
809 depending on your engine use. If you are only using software, enable word
810 caching (and neon on arm if you can), for GL, turn on metric caching.
811 A simple solution is enable both, and let the engine sort it out at run time.
813 If you have any issues with metric caching, please report them to either
814 the e-devel mailing list or Brett Nash <nash@nash.id.uau>
819 this enables fontconfig support for loading font files by using
820 generic fontconfig font names and styles. you really should use this
821 by default on any linux/unix platform for universal font support.
826 this enables support for the fribidi library to have right to left and
827 left to right font rendering so languges such as arabic, hebrew and
828 other "RTL" langauges display properly.
831 --enable-evas-magic-debug
833 this allows you to enable and disable evas's extra magic number
834 checks. these allow better stability with runtime object magic
835 "number" checks to make sure you are accessing a real object in memory
836 of the right type, and will avoid doing "bad things" if they detect
837 the wrong object type being passed in. if you are absolutely sure your
838 system has no bugs in accessing objects of the wrong type with the
839 wrong calls, you can gain some small performance by disabling this.
842 ------------------------------------------------------------------------------
845 For the arm optimizations you want to try:
846 export CFLAGS="-O2 -march=armv5te -mcpu=arm1136jf-s -fomit-frame-pointer"
848 To enable the async renderer compile with:
849 --enable-async-render
850 and also runtime set this environment variable:
851 export EVAS_RENDER_MODE=non-blocking
853 For compilation with MinGW, fnmatch.h is probably missing. That file can be
855 http://www.koders.com/c/fid2B518462CB1EED3D4E31E271DB83CD1582F6EEBE.aspx
856 It should be installed in the mingw include directory.