forked from enlightenment/efl
670 lines
24 KiB
Plaintext
670 lines
24 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 (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 optimizations 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 internationalized 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 you are installing in your users directories):
|
|
make install
|
|
|
|
if you want to know what options to enable
|
|
./configure --help
|
|
|
|
Evas's rendering code assumes a decently optimizing compiler. For
|
|
example gcc with -O2 -march=nocona for example (compile for core2 duo
|
|
x86 or better). Yoiu may choose not to compile for a very modern
|
|
architecture, and Evas still has MMX/SSE, NEON and other hand-crafted
|
|
assembly, but not for everything, so make use of your compiler
|
|
optimizing as much as possible. At least use -O2 or equivalents.
|
|
|
|
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 (--enable-FEATURE enables it and --disable-FEATURE
|
|
disables it, some being enabled or disabled by default or if
|
|
dependencies are found):
|
|
|
|
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.
|
|
|
|
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 noticeable, 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 forgo the speed.
|
|
|
|
--enable-line-dither-mask
|
|
|
|
this is a faster alternative to the small or large dither masks above.
|
|
this dithers only on an alternating-line basis. this only provides 1
|
|
intermediate "dither" level whose odd and even pixels alternate
|
|
between the 2 closest colors available, but it is very fast. almost as
|
|
fast as no dithering. quality though will not be as good as small or
|
|
default "large" dither masks.
|
|
|
|
--enable-no-dither-mask
|
|
|
|
this disables dithering entirely. this is the fastest option, but the
|
|
lowest quality. not suggested in general unless you are really in need
|
|
of an extra few percent speed and are willing to have fairly awful
|
|
quality. but in general this is the standard rendering for most
|
|
"realtime graphics" if it has to drop to lower bit-depths, so it's
|
|
not anything unusual. just in the evas world the quality is considered
|
|
poor enough to be discouraged as evas's internal rendering is so much
|
|
higher quality.
|
|
|
|
ENGINES:
|
|
--enable-software-xlib
|
|
|
|
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 xlib 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. this engine is
|
|
specifically geared towards people writing minimalist display systems for
|
|
embedded devices such as the ipaq, zaurus, etc. it also scales up to high-res
|
|
desktop systems as
|
|
well.
|
|
|
|
--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). as such this engine is in relative disrepair and is not
|
|
maintained. use with great care.
|
|
|
|
--enable-buffer
|
|
|
|
this enables the memory buffer rendering engine. this engine renders
|
|
to a region of memory that is considered to be a 32bit ARGB buffer of
|
|
pixels, allowing the results of rendering to be directly read out or
|
|
used again for other purposes.
|
|
|
|
--enable-xrender-x11
|
|
|
|
this engine uses the xrender api to do drawing via (possibly)
|
|
accelerated 2d or 3d hardware means. as such xrender has never lived
|
|
up to its possible performance levels and has fallen into disrepair.
|
|
use this engine at your own risk. it is considered to be "bitrotting"
|
|
and be unmaintained.
|
|
|
|
--enable-xrender-xcb
|
|
|
|
this is the same as xrender-x11 but uses/exposes an xcb api.
|
|
|
|
--enable-gl-x11
|
|
|
|
this is the opengl engine. it is intended for an x11 target (via xlib)
|
|
rather than framebuffer (even if you use EGL, the EGL flavor is
|
|
expected to be an x11 one). it is a full opengl based rendering engine
|
|
with all rendering implemented as a texture + triangle pipeline and
|
|
more. it also supports opengl-es2.0 and is reliant on modern opengl2.0+
|
|
shader support. this engine also supports the native surface api for
|
|
adopting pixmaps directly to textures for compositing.
|
|
|
|
--enable-gl-flavor-gles
|
|
|
|
this enables the opengl-es 2.0 flavor of opengl (as opposed to desktop
|
|
opengl) when building evas's gl-x11 engine above. this will be needed
|
|
if you are building evas for opengl-es 2.0 enabled embedded devices.
|
|
evas works on several opengl-es 2.0 compliant gpu's and gains more
|
|
testing and optimization regularly. it is also capable of
|
|
texture-from-pixmap support in opengl-es like it is in desktop opengl.
|
|
|
|
--enable-gles-variety-sgx
|
|
|
|
this tells evas that you are building the gl-es engine for a
|
|
shader-compiler "sgx style" opengl-es 2.0 implementation. this is
|
|
where the shader compiler is provided at runtime and can accept the
|
|
shader glsl source and work
|
|
|
|
--enable-gles-variety-s3c6410
|
|
|
|
this tells evas that you have an s3c6410 style opengl-es
|
|
implementation that has an offline shader compiler and that needs
|
|
pre-compiled shader binaries (provided with evas). this has not been
|
|
tested in quite a while as the drivers and environment for this system
|
|
have gone missing
|
|
|
|
--enable-software-gdi
|
|
|
|
windows gdi based engine for evas
|
|
|
|
--enable-software-ddraw
|
|
|
|
windows direct-draw engine for evas
|
|
|
|
--enable-direct3d
|
|
|
|
evas direct3d engine (experimental)
|
|
|
|
--enable-quartz
|
|
|
|
macos-x quartz engine (experimental)
|
|
|
|
--enable-gl-glew
|
|
|
|
opengl glew based gl engine for evas (experimental)
|
|
|
|
--enable-software-sdl
|
|
|
|
this is the sdl engine that uses sdl library (http://www.libsdl.org). This
|
|
library should work on many operating system. the buffer is
|
|
software-rendered with evas's default software rendering core.
|
|
|
|
--enable-gl-sdl
|
|
|
|
opengl (and opengl-es2.0) rendering engine that uses sdl as the front
|
|
end interface. see --enable-gl-x11 etc. for information.
|
|
|
|
--enable-software-8-x11
|
|
|
|
8bit only rendering core. intended for greyscale output on things like
|
|
e-paper or simplistic greyscale LCD devices which have no color.
|
|
|
|
--enable-software-16-x11
|
|
|
|
16bit specific renderer. lower quality than the default. also limited
|
|
in abilities. in a state of disrepair. do not use.
|
|
|
|
--enable-software-16-ddraw
|
|
|
|
16bit renderer for direct-draw. same as software-16-x11 - don't use.
|
|
in disrepair.
|
|
|
|
--enable-software-16-wince
|
|
|
|
same as software-16-ddraw but for windows-ce. in disrepair. don't use.
|
|
|
|
CPU:
|
|
--enable-cpu-c
|
|
|
|
this enabled the c code. you can actually build the code without the c
|
|
fallback code and only have the mmx routines for example. it is suggested to
|
|
always use this regardless unless you have some definite size issues with the
|
|
code.
|
|
|
|
--enable-cpu-mmx
|
|
|
|
this enables the mmx optimized 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 optimizations) in speed.
|
|
|
|
--enable-cpu-sse
|
|
|
|
this enables sse optimizations available 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.
|
|
|
|
--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>
|
|
|
|
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. this
|
|
loader also supports load options to pre-scale jpeg images down to
|
|
provide much faster load times while also getting downscaling by 1/2,
|
|
1/4 or 1/8th the size in each dimension for "free". with an added
|
|
patch to libjpeg7, it can also fast-decode a specific region of a jpeg
|
|
file (without the patch it take a slow-path to do this).
|
|
|
|
--enable-image-loader-edb
|
|
|
|
edb image loader- can load images inside edb database files. not very
|
|
useful as edb itself is no longer used by enlightenment. may be
|
|
removed at some point, so unless you have a burning need for this,
|
|
don't use edb files to store image data and rely on this loader
|
|
|
|
--enable-image-loader-eet
|
|
|
|
loads image data from eet files. eet files are the backing for edje
|
|
storage, so this is needed for edje to work. it is very useful as it
|
|
can load an image from anywhere in the eet archive by key value so eet
|
|
files are like "zip" files where you can pack a whole lot of image and
|
|
other data together and just pick out the pieces you need at runtime.
|
|
requires the eet library.
|
|
|
|
--enable-image-loader-gif
|
|
|
|
gif image loader. gif is an obsolete format, but due to its longevity,
|
|
sitll has lots of existing data around.
|
|
|
|
--enable-image-loader-pmaps
|
|
|
|
ppm/pnm/pgm image loader that can load the "pnm" style image format.
|
|
not very common, but the files are simple raw RGB, greyscale image or
|
|
bitmap data in binary or ascii format
|
|
|
|
--enable-image-loader-svg
|
|
|
|
this loader can load svg files via librsvg (thus it is a dependency).
|
|
this loader supports load options to set the dpi to decode the svg at
|
|
etc. which can then be used to create scalable images that scale to
|
|
any size without becoming blocky or blurry, if the source is an svg
|
|
file.
|
|
|
|
--enable-image-loader-tiff
|
|
|
|
this loader uses libtiff to load tiff image files
|
|
|
|
--enable-image-loader-xpm
|
|
|
|
this is an xpm format image loader. xpm format images are ascii files
|
|
that look like c/c++ source code that contain images. these files are
|
|
old-fashioned unix+x11 images you may encounter, but are inefficient
|
|
for storage and decoding and have been superseded by png files in
|
|
almost every way
|
|
|
|
--enable-image-loader-bmp
|
|
|
|
this enables the bmp image format loader. note that there seems to be
|
|
a disagreement on 32bit bmp format images where alpha channels are
|
|
concerned and you may run into issues with bmps generated by the gimp
|
|
that have alpha channels. there is a problem where they don't seem to
|
|
be spec-conformant.
|
|
|
|
--enable-image-loader-tga
|
|
|
|
this loader load tga format files. these files are very old-fashioned
|
|
but found often in the 3d graphics world.
|
|
|
|
FONT LOADERS:
|
|
--enable-font-loader-eet
|
|
|
|
this loader can load font (ttf) files directly from eet archives like
|
|
the eet image loader. requires the eet library
|
|
|
|
CONVERTERS:
|
|
--enable-convert-yuv
|
|
|
|
this enables an optimized yuv (yv12 601 colorspace) to ARGB32
|
|
converter in evas
|
|
|
|
--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 assumes the upper 4 bits fo each color primitive 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
|
|
displays 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) converters for 16bpp.
|
|
this is the standard display mode for things like pocketpc on the ipaq and
|
|
the zaurus etc. this is an optimized part of the rendering pipeline to allow
|
|
portrait display with a much lower overhead than doing it through X.
|
|
|
|
--enable-convert-16-rgb-rot-180
|
|
|
|
same as --enable-convert-16-rgb-rot-270 but for 180 degrees
|
|
|
|
--enable-convert-16-rgb-rot-90
|
|
|
|
same as --enable-convert-16-rgb-rot-270 but for 90 degrees
|
|
|
|
--enable-convert-24-rgb-888
|
|
|
|
this converts evas's 32bit ARGB to 24bit RGB packed format for output
|
|
if needed
|
|
|
|
--enable-convert-24-bgr-888
|
|
|
|
this converts evas's 32bit ARGB to 24bit packed BGR format for output
|
|
if needed
|
|
|
|
--enable-convert-32-rgb-8888
|
|
|
|
32bit RGB output conversion support. byteswapping compared to evas's
|
|
native colorspace
|
|
|
|
--enable-convert-32-bgr-8888
|
|
|
|
conversion (reduces toa memory copy) from evas's native colorspace to
|
|
the same color format.
|
|
|
|
--enable-convert-32-rgb-rot-0
|
|
|
|
copies without rotation evas's native image format
|
|
|
|
--enable-convert-32-rgb-rot-270
|
|
|
|
copies evas's native ARGB32 pixels but at a rotation of 270 degrees.
|
|
|
|
--enable-convert-32-rgb-rot-180
|
|
|
|
same as --enable-convert-32-rgb-rot-270 but for 180 degrees
|
|
|
|
--enable-convert-32-rgb-rot-90
|
|
|
|
same as --enable-convert-32-rgb-rot-270 but for 90 degrees
|
|
|
|
--enable-convert-24-rgb-ezx
|
|
|
|
a special colorspace handler for 18bit color packed into 24bit output
|
|
(where only 6 bits per r, g and b byte are used). the only known
|
|
platform that did this was the motorola esx based phones that used
|
|
qtopia originally and have open ezx ports for them.
|
|
|
|
--enable-convert-8-gry-1
|
|
|
|
enable 8bit gray to 1 bit black & white converter
|
|
|
|
--enable-convert-8-gry-16
|
|
|
|
8bit grey to 16 level grayscale converter
|
|
|
|
--enable-convert-8-grayscale-64
|
|
|
|
8bit grey to 64 level grayscale converter
|
|
|
|
--enable-convert-8-rgb-332
|
|
|
|
enable converter from 32bit ARGB to 8bit color "332" colorspace (3bits
|
|
red, 3 bits green, 2 bits blue)
|
|
|
|
--enable-convert-8-rgb-666
|
|
|
|
enable converter from 32bit ARGB to 8bit color "216" "websafe"
|
|
colorspace (6 values for red, 6 for green and 6 for blue - 6x6x6 being
|
|
216 colors).
|
|
|
|
--enable-convert-8-rgb-232
|
|
|
|
same as convert-8-rgb-332 but 2 bits red, 3 green, 2 blue
|
|
|
|
--enable-convert-8-rgb-222
|
|
|
|
same as convert-8-rgb-332 but 2 bits red, 2 green, 2 blue
|
|
|
|
--enable-convert-8-rgb-221
|
|
|
|
same as convert-8-rgb-332 but 2 bits red, 2 green, 1 blue
|
|
|
|
--enable-convert-8-rgb-121
|
|
|
|
same as convert-8-rgb-332 but 1 bit red, 2 green, 1 blue
|
|
|
|
--enable-convert-8-rgb-111
|
|
|
|
same as convert-8-rgb-332 but 1 bit red, 1 green, 1 blue. this is the
|
|
lowest sized colorspace supported for rgb (3bits, 8 color).
|
|
|
|
MISC:
|
|
--enable-pthreads
|
|
|
|
this enables pthread support in evas so multiple threads may run
|
|
internally for parallel rendering, loading etc.
|
|
|
|
--enable-async-events
|
|
|
|
this provides the ability for evas to have an asynchronous event
|
|
notification pipe to provide events when background threads are done
|
|
with tasks, like pre-loading image files
|
|
|
|
--enable-async-preload
|
|
|
|
evas can load images (preload) them in the background using a thread
|
|
if you ask it to, and provide events when done. this goes hand-in-hand
|
|
with --enable-pthreads and --enable-async-events. you really want all
|
|
of these available.
|
|
|
|
--enable-async-render **CAUTION - MAY NOT WORK RIGHT**
|
|
|
|
this enables a software multi-frame threaded renderer. this will
|
|
allocate (for example) 2 frames to 2 cores, with one core of the cpu
|
|
rendering the previous frame while the next frame starts rendering on
|
|
another core in the meantime allowing for higher framerates with
|
|
software rendering, using more cpu resources that are available on
|
|
modern multi-core cpu's.
|
|
|
|
This has been tested on x86 desktop and laptop cpu's with 2 and 4
|
|
cores and it works well, but there seem to be some issues on tested
|
|
multi-core ARM platforms like the nvidia tegra2. The source of issue is
|
|
unknown but you will notice rendering bugs with missing content or
|
|
incorectly drawn content. This requires you also set the environment
|
|
variable EVAS_RENDER_MODE to "non-blocking" to enable it at runtime,
|
|
as the compile-time enable simply sets up the feature to be ready to
|
|
work. The runtime switch actually turns it on. If you don't plan to
|
|
use this feature, don't enable it in the build as there is a general
|
|
performance hit of maintaining this feature at all, so beware that
|
|
enabling it for single core systems will likely take a performance hit.
|
|
|
|
--enable-pipe-render **DISABLED DUE TO BUGS**
|
|
|
|
this enables a multiple-thread renderer that divides the rendering
|
|
into N regions (1 per core) to speed up rendering in software when you
|
|
have multiple cpu cores.
|
|
|
|
--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 back-ends 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 e-devel 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 e-devel mailing list or Brett Nash <nash@nash.id.uau>
|
|
|
|
--enable-fontconfig
|
|
|
|
this enables fontconfig support for loading font files by using
|
|
generic fontconfig font names and styles. you really should use this
|
|
by default on any linux/unix platform for universal font support.
|
|
|
|
--enable-fribidi
|
|
|
|
this enables support for the fribidi library to have right to left and
|
|
left to right font rendering so languges such as arabic, hebrew and
|
|
other "RTL" langauges display properly.
|
|
|
|
--enable-evas-magic-debug
|
|
|
|
this allows oyu to enable and disable evas's extra magic number
|
|
checks. these allow better stability with runtime object magic
|
|
"number" checks to make sure you are accessing a real object in memory
|
|
of the right type, and will avoid doing "bad things" if they detect
|
|
the wrong object type being passed in. if you are absolutely sure your
|
|
system has no bugs in accessing objects of the wrong type with the
|
|
wrong calls, you can gain some small performance by disabling this.
|
|
|
|
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/
|
|
|