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