diff --git a/legacy/evas/README.in b/legacy/evas/README.in new file mode 100644 index 0000000000..195236b700 --- /dev/null +++ b/legacy/evas/README.in @@ -0,0 +1,269 @@ +Evas @VERSION@ + +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. + +-------------------------------------------------------------------------- +Requires: + + freetype 2.x.x (I want to make this optional) + +Optional: + + X11R6 + DirectFB + OpenGL (underway at the moment) + Linux + Qtopia + libpng + libjpeg + libeet + libedb + +-------------------------------------------------------------------------- +Evas as of 0.9.9 has a new (and incompatible) API. Why? It's much cleaner +and more compact. Designed for portable access to different display systems. +It is also much more optimised internally, uses much less ram than previous +Evas libraries, and is tiny. Evas when compiled for the Ipaq is a grand +total of 191Kb (thats all of Evas minus libjpeg, libpng, libz (required for +libpng), and minus freetype (required for font rendering)). I have plans that +may involve having an alternative font engine other than freetype to minimise +requirements, and having a native (optional) image loader for an image +format that may end up being custom to evas, but will minimise code & +requirements especially for embedded use. + +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 charcters do. + +-------------------------------------------------------------------------- +if you want to know what options to enable +./confiugre --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. + freetype 2.1.2 is BAD. RedHat 8.0 uses this as do some debain distributions. + either downgrade to 2.1.1. freetype 2.1.3 is ALSO BAD, as is 2.0.9. It has + glyph metric rendering bugs and glyph geomery query bugs. do not use it. + try using 2.0.3. It is known to be stable and work perfectly with Evas. + +-------------------------------------------------------------------------- +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 si a godo generic engine that is fast and can run in X for good +development and debugging purposes. + +--enable-fb + +this is the software framebuffer drivign engine. this uses the linxu +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). + +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 penitum, 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 whht all optimisations) in speed. + +--enable-cpu-sse + +this enables sse optimisations 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 whht all optimisations) 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 use sless 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 disp;ay and you shoudl 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 optimised 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... + +... + + +------------------------------------------------------------------------------ +COMPILING AND INSTALLING: + + ./configure + make +(as root unless youa re installing in your users directories): + make install + +------------------------------------------------------------------------------ +BUILDING PACKAGES: + +RPM: To build rpm packages: + + sudo rpm -ta @PACKAGE@-@VERSION@.tar.gz + +You will find rpm packages in your system /usr/src/redhat/* dirs (note you may +not need to use sudo or root if you have your own ~/.rpmrc. see rpm documents +for more details) + +DEB: To build deb packages: + + tar zvf @PACKAGE@-@VERSION@.tar.gz + cd @PACKAGE@-@VERSION@ + dpkg-buildpackage -us -uc -rfakeroot + cd .. + rm -rf @PACKAGE@-@VERSION@ + +You will find all the debian source, binary etc. packages put in the directory +where you first untarred the source tarball.