forked from enlightenment/efl
324 lines
12 KiB
Plaintext
324 lines
12 KiB
Plaintext
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 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<x>) 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 <nash@nash.id.uau>
|
|
|
|
--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 <nash@nash.id.uau>
|
|
|
|
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 <nash@nash.id.uau>
|
|
|
|
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/
|
|
|