Evas @VERSION@ ALPHA ****************************************************************************** FOR ANY ISSUES PLEASE EMAIL: enlightenment-devel@lists.sourceforge.net ****************************************************************************** Requirements: ------------- Must: libc libm eina (1.0.0 or better) freetype (2.1.9 or better) Recommended: libX11 libXext libXrender fontconfig libpng libjpeg eet (1.4.0 or better) libpthread Optional: XCB SDL OpenGL Qtopia librsvg libtiff libgif edb DirectFB Evas is a clean display canvas API for several target display systems that can draw anti-aliased text, smooth super and sub-sampled scaled images, alpha-blend objects much and more. Evas is designed to be portable to different display systems. Evas uses very little RAM too (try profiling it in memprof if you want to know) most of the ram allocated, if you look, is for freetype itself, image pixel data, and font glyph data. You can't really avoid this, though evas tries to share this data as much as possible and not duplicate where it can. Feel free to point me at sensible memory optimisations etc. though :) I want this baby to be lean, mean tiny, fast and do everything from your massive multi-cpu desktop with gobs of ram and disk to a tiny watch. Evas also supports full UTF-8 for text object strings, thus allowing for full internationalised text strings (if your font gives you all the characters). I've tested with quite a few fonts and it works quite well. Though this requires a unicode compatible font with unicode charmap support (cyberbit is quite good actually as a font). For now Evas draws the fonts only from left to right, so arabic, hebrew etc. won't display quite right, direction-wise, but the characters do. ------------------------------------------------------------------------------ COMPILING AND INSTALLING: ./configure make (as root unless youa re installing in your users directories): make install if you want to know what options to enable ./configure --help Notes: the small dither mask is faster on the ipaq, but is not as good looking. on desktop machines it makes no speed difference so only use --enable-small-dither-mask if you are compiling for the ipaq you need at least 1 image loader if you want to load images. gcc 3.0.x on solaris screws up the jpeg code so erroring out doesn't work. use gcc 3.2 on solaris. notes on features: SCALING: --enable-scale-sample this enables the sampling scaler code. this is the fastest image scaling code, but also the lowest quality. when scaling up pixels will become blocky and when scaling down you will see shimmering/aliasing artifacts. this is a speed vs. quality tradeoff --enable-scale-smooth this is the nicest looking scaler that is not that much slower than tri-linear, but it looks really good. it also uses mipmaps and is optimised heavily. it is recommended to always use this unless you are really struggling for speed and are qilling to forego the quality DITHERING: --enable-small-dither-mask this uses a 4x4 dither mask instead of 128x128. on desktop boxes these days (pentium, pentium2, amd etc.) the speed difference is not really measurable, but the quality of the 128x128 dither mask is quite a lot better. patterns of dithering are much less noticable, so it is recommended to not enable this unless you are struggling for speed. the compaq ipaq for example shows a slowdown with this large a dither mask so enabling a small dither mask is recommended unless you really want to forego the speed. ENGINES: --enable-software-x11 this enables the software x11 rendering engine that renders to X drawable targets using highly optimised software routines. there is no hardware assist here. this engine requires X11 to be installed to build (and run). This is a godo generic engine that is fast and can run in X for good development and debugging purposes. --enable-software-xcb this enable the software xcb rendering engine. It allows the same features than the software x11 engine. It require the XCB and XCBImage libraries. For the test programs, XCBICCCM is also needed. --enable-fb this is the software framebuffer driving engine. this uses the linux framebuffer device (/dev/fb) and will currently just inherit the current framebuffer settings on the fb device and use them to run in. this engine is almost fully functional except for the fb management itself. i'd be quite happy for people to help out with fixing up the fb init & management code to properly set up a vt and release it etc. this engine is specifically geared towards peoel writing minimalist display systems for embedded devices such as the ipaq, zaurus, etc. it also scales up to high-res desktop systems as well and performs outstandingly. i have measured up to 67% speedup over X11 using the fb driver insetad of X11. --enable-direcfb this is the direct fb engine that uses direcftb (http://www.directfb.org) on linux to access the framebuffer with (or maybe without) acceleration. for people making set-top boxes or just wanting an alternative to X this is really good. it may also be useful for embedded devices supported by directfb that offer acceleration (otherwise the fb driver will likely be faster). --enable-sdl this is the sdl engine that uses sdl library (http://www.libsdl.org). This library should work on many operating system. CPU: --enable-cpu-c this enabled the c code. you can actually build the code withotu the c fallback code and only have the mmx routines for example. it is suggested to always use this regardless uness you have some definite size issues with the code. --enable-cpu-mmx this enables the mmx optimised routines. this works for pentium, pentium2, pentium3, pentium4, athlon and duron processors. it can get quite considerable speedups, souse it if you can. ppc owners just have to live with the c fallback functions unfortunately as no one has provided any ALTIVEC asm routines yet. :) arm owners will also have to rely on the c fallback routines as i haven't managed to come up with any arm assembly that actually can beat the c code (when compiled with all optimisations) in speed. --enable-cpu-sse this enables sse optimizations availbale in he pentium3 and 4 cpus (not athlon and duron or pentium 2 or pentium cpu's). ppc owners just have to live with the c fallback functions unfortunately as no one has provided any ALTIVEC asm routines yet. :) arm owners will also have to rely on the c fallback routines as i haven't managed to come up with any arm assembly that actually can beat the c code (when compiled with all optimizations) in speed. IMAGE LOADERS: --enable-image-loader-png this enables the loader code that loads png files using libpng. there may be call for embedded devices later that have custom written small image loaders that uses less disk space than libpng to load custom format images. for now this is the only loader so you may as well include it. --enable-image-loader-jpeg this enables the loader code that loads jpeg files using libjpeg. CONVERTERS: --enable-convert-16-rgb-565 the most common converter you'll want for 16bpp. this means 5 bits for red, 6 bits for green and 5 bits for blue are used. --enable-convert-16-rgb-555 this is a converter for what many people know as "15 bit" color. you might want to enable this for X output as it used to be common to find many cards that do this. --enable-convert-16-rgb-444 this converter outputs to 12bit packed (int 16 bit WORDS). --enable-convert-16-rgb-ipq this converter was written specifically for the ipaq (and may apply to similarly configured devices) because it lies about its screen depth. it says it is 16bit 565 (that means 5 upper bits of the WORD are red, the next 6 bits are for green abd the next 5 for blue) but in fact only the upper 4 bits of each color component (red green and blue) are significant and work, so effectively the display is 12 bits of color, not 16, but padded out to fill 16bits, with unused bits in the color masks. X on the ipaq advertises it as a full 16bpp 565 display (i can't remember what the linux framebuffer advertised it as) and so many lumps of code can be fooled into rendering data badly because they think the output will look as the expect. This renderer assuems the upper 4 bits fo each color primitie only are significant and renders accordingly. this produces nice quality images on the ipaq and even still works in 16bpp 565 on your pc. it is highly recommended to use this renderer if your target is an ipaq or your device dislpays similar qualities of the ipaq for display purposes. --enable-convert-16-rgb-rot-0 this enables the 16bpp converters to run with 0 degrees rotation - this is normal display and you should really include this (though it is optional if you only ever want to do portrait mode - perhaps like on an ipaq embedded device) --enable-convert-16-rgb-rot-270 this enables the portrait mode (270 degree rotation) converteres for 16bpp. this is the standard display mode for things like pocketpc on the ipaq and the zaurus etc. thsi si a optimized part of the rendering pipeline to allow portrait display with a much lower overhead than doing it through X. --enable-convert-24-rgb-888 To be documented... --enable-convert-24-bgr-888 To be documented... --enable-convert-32-rgb-8888 To be documented... --enable-convert-32-bgr-8888 To be documented... --enable-convert-32-rgb-rot-0 To be documented... --enable-convert-32-rgb-rot-270 To be documented... ... --enable-cpu-neon This enables support for the Arm Cortex-A8 and later Neon register set. In particular it will use neon optimised code for rotations and drawing with the software engines. Open GL based renderers will gain nothing from the use of neon. To use neon with gcc-4.4 you need a post-2009 gcc and options something like: -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon Note that this slightly slows down non-optimised parts of evas but the gains in drawing are more then worth it overall. This is enabled by default, and turns off if a small test program is unable to compile. Performance is at least 50%, and in some real world tests approaches 100%. If you have any issues with neon, please report them to either the edevel mailing list or Brett Nash --enable-word-cache Cache rendered words and draw them as a single object, instead of individual characters. This is a big gain for things like neon which draw large runs effectively. However it is useless on GL and similar backends as the cost in sending a word sized texture kills the performance gain (and GL is pretty good at drawing lots of small things anyway). By default words (strings) of more then 50 characters are not cached. The system caches 40 words by default, but this can be changed by setting EVAS_WORD_CACHE_MAX_WORDS to another number. Setting it to 0 will disable word-cache at run time. Text based benchmarks are 50-100% quicker. If you have any issues with word caching, please report them to either the edevel mailing list or Brett Nash For GL see metric caching... --enable-metric-cache Metric caching saves character metrics between characters in words. This enables it to render words much quicker as it avoids things like space calculations and kerning calculation. The cache seize is also controlled by EVAS_WORD_CACHE_MAX_WORDS It is useful for GL in particular, although software engines do get some gain. Generally it is recommended you enable either word or metric caching, depending on your engine use. If you are using software, enable word caching (and neon on arm if you can), for GL, turn on metric caching. If you have any issues with metric caching, please report them to either the edevel mailing list or Brett Nash NOTES: For the arm optimizations you want to try: export CFLAGS="-O2 -march=armv5te -mcpu=arm1136jf-s -fomit-frame-pointer" To enable the async renderer compile with: --enable-async-render and also runtime set this environment variable: export EVAS_RENDER_MODE=non-blocking For compilation with MinGW, fnmatch.h is probably missing. That file can be found here: http://www.koders.com/c/fid2B518462CB1EED3D4E31E271DB83CD1582F6EEBE.aspx It should be installed in the mingw include directory. For the OpenGL engine on Windows, the glew library is needed: http://glew.sourceforge.net/