3
******************************************************************************
5
FOR ANY ISSUES PLEASE EMAIL:
6
enlightenment-devel@lists.sourceforge.net
8
******************************************************************************
15
eina (1.6.0 or better)
17
freetype (2.1.9 or better)
20
libX11 + libXext + libXrender
21
OpenGL2.0 or OpenGL-ES 2.0
24
libjpeg (6.0 or better)
31
XCB SDL esvg libtiff libwebp libgif edb DirectFB evas_generic_loaders
33
Evas is a clean display canvas API for several target display systems
34
that can draw anti-aliased text, smooth super and sub-sampled scaled
35
images, alpha-blend objects much and more.
37
Evas is designed to be portable to different display systems. Evas uses very
38
little RAM too (try profiling it in memprof if you want to
39
know) most of the ram allocated, if you look, is for freetype itself,
40
image pixel data, and font glyph data. You can't really avoid this, though
41
evas tries to share this data as much as possible and not duplicate where it
42
can. Feel free to point me at sensible memory optimizations etc. though :) I
43
want this baby to be lean, mean tiny, fast and do everything from your
44
massive multi-cpu desktop with gobs of ram and disk to a tiny watch.
46
Evas also supports full UTF-8 for text object strings, thus allowing for
47
full internationalized text strings (if your font gives you all the
48
characters). I've tested with quite a few fonts and it works quite well.
49
Though this requires a unicode compatible font with unicode charmap support
50
(cyberbit is quite good actually as a font). For now Evas draws the fonts
51
only from left to right, so arabic, hebrew etc. won't display quite right,
52
direction-wise, but the characters do.
54
------------------------------------------------------------------------------
55
COMPILING AND INSTALLING:
59
(as root unless you are installing in your users directories):
62
if you want to know what options to enable
65
Evas's rendering code assumes a decently optimizing compiler. For
66
example gcc with -O2 -march=nocona for example (compile for core2 duo
67
x86 or better). You may choose not to compile for a very modern
68
architecture, and Evas still has MMX/SSE, NEON and other hand-crafted
69
assembly, but not for everything, so make use of your compiler
70
optimizing as much as possible. At least use -O2 or equivalents.
73
the small dither mask is faster on the ipaq, but is not as good looking. on
74
desktop machines it makes no speed difference so only use
75
--enable-small-dither-mask if you really need the speed for low depth
76
you need at least 1 image loader if you want to load images.
77
gcc 3.0.x on solaris screws up the jpeg code so erroring out doesn't work.
78
use gcc 3.2 on solaris.
80
notes on features (--enable-FEATURE enables it and --disable-FEATURE
81
disables it, some being enabled or disabled by default or if
82
dependencies are found):
84
Also the wayland support (EGL and SHM engines) is considered experimental as
85
wayland itself is still unstable and liable to change core protocol.
86
If you use this api, it is possible it will break in future, until this
89
------------------------------------------------------------------------------
93
this enables the sampling scaler code. this is the fastest image scaling
94
code, but also the lowest quality. when scaling up pixels will become blocky
95
and when scaling down you will see shimmering/aliasing artifacts. this is a
96
speed vs. quality tradeoff
101
this is the nicest looking scaler that is not that much slower than
102
tri-linear, but it looks really good.
105
------------------------------------------------------------------------------
107
--enable-small-dither-mask
109
this uses a 4x4 dither mask instead of 128x128. on desktop boxes these days
110
(pentium, pentium2, amd etc.) the speed difference is not really measurable,
111
but the quality of the 128x128 dither mask is quite a lot better. patterns
112
of dithering are much less noticeable, so it is recommended to not enable
113
this unless you are struggling for speed. the compaq ipaq for example shows
114
a slowdown with this large a dither mask so enabling a small dither mask is
115
recommended unless you really want to forgo the speed.
118
--enable-line-dither-mask
120
this is a faster alternative to the small or large dither masks above.
121
this dithers only on an alternating-line basis. this only provides 1
122
intermediate "dither" level whose odd and even pixels alternate
123
between the 2 closest colors available, but it is very fast. almost as
124
fast as no dithering. quality though will not be as good as small or
125
default "large" dither masks.
128
--enable-no-dither-mask
130
this disables dithering entirely. this is the fastest option, but the
131
lowest quality. not suggested in general unless you are really in need
132
of an extra few percent speed and are willing to have fairly awful
133
quality. but in general this is the standard rendering for most
134
"realtime graphics" if it has to drop to lower bit-depths, so it's
135
not anything unusual. just in the evas world the quality is considered
136
poor enough to be discouraged as evas's internal rendering is so much
140
------------------------------------------------------------------------------
143
All engines can be compiled statically inside libevas.so in order to
144
reduce runtime time at dynamically loaded modules. All you have to do
145
is to enable your chosen modules with "=static" suffix. If they depend
146
on software_generic (most do), you need that as well. Examples:
148
./configure --enable-static-software-generic --enable-software-xlib=static
151
--enable-software-xlib[=static]
153
this enables the software x11 rendering engine that renders to X drawable
154
targets using highly optimized software routines. there is no hardware
155
assist here. this engine requires X11 to be installed to build (and run).
156
This is a good generic engine that is fast and can run in X for good
157
development and debugging purposes.
160
--enable-software-xcb[=static]
162
this enable the software xcb rendering engine. It allows the same
163
features than the software xlib engine. It require the XCB and XCBImage
164
libraries. For the test programs, XCBICCCM is also needed. It is not
165
recommended to use this as it's experimental and will create problems
166
with both ecore_evas and enlightenment itself.
171
this is the software framebuffer driving engine. this uses the linux
172
framebuffer device (/dev/fb{X}) and will currently just inherit the current173
framebuffer settings on the fb device and use them to run in. this engine is
174
almost fully functional except for the fb management itself. this engine is
175
specifically geared towards people writing minimalist display systems for
176
embedded devices such as the ipaq, zaurus, etc. it also scales up to high-res
181
--enable-directfb[=static]
183
this is the direct fb engine that uses direcftb (http://www.directfb.org) on
184
linux to access the framebuffer with (or maybe without) acceleration. for
185
people making set-top boxes or just wanting an alternative to X this is
186
really good. it may also be useful for embedded devices supported by
187
directfb that offer acceleration (otherwise the fb driver will likely be
188
faster). as such this engine is in relative disrepair and is not
189
maintained. use with great care.
192
--enable-buffer[=static]
194
this enables the memory buffer rendering engine. this engine renders
195
to a region of memory that is considered to be a 32bit ARGB buffer of
196
pixels, allowing the results of rendering to be directly read out or
197
used again for other purposes.
200
--enable-gl-x11[=static]
202
this is the opengl engine. it is intended for an x11 target (via xlib)
203
rather than framebuffer (even if you use EGL, the EGL flavor is
204
expected to be an x11 one). it is a full opengl based rendering engine
205
with all rendering implemented as a texture + triangle pipeline and
206
more. it also supports opengl-es2.0 and is reliant on modern opengl2.0+
207
shader support. this engine also supports the native surface api for
208
adopting pixmaps directly to textures for compositing.
210
some environment variables that control the opengl engine are as
214
set this environment variable to enable output of opengl information
215
such as vendor, version, extensions, maximum texture size etc. unset
216
the environment variable to make the output quiet again.
218
export EVAS_GL_MEMINFO=1
219
set this environment variable to enable dumping of debug output
220
whenever textures are allocated or freed, giving the number of
221
textures of each time and how many kb worth of pixel data are
222
allocated for the textures. unset it again to stop this dumping of
225
export EVAS_GL_WIN_RESURF=1
226
set this environment variable to enable the gl engine to try and
227
ddelete the window surface, if it can, when told to "dump resources"
228
to save memory, and re-allocate it when needed (when rendering
229
occurs). unset it to not have this behavior.
231
export EVAS_GL_CUTOUT_MAX=N
232
set this environment variable to the maximum number of rectangles
233
applied to a rendering of a primitive that "cut away" parts of that
234
primitive to render to avoid overdraw. default is 512. unset it to use
235
defaults, otherwise set N to the max value desired or to -1 for
236
"unlimited rectangles".
238
export EVAS_GL_PIPES_MAX=N
239
set the maximum number of parallel pending pipelines to N. the
240
default number is 32 (except on tegra2 where is it 1). evas keeps 1 (or more)
241
pipelines of gl draw commands in parallel at any time, to allow for merging
242
of non-overlapping draw commands to avoid texture binding and context
243
changes which allows for more streamlining of the draw arrays that are
244
filled and passed to gl per frame. the more pipelines exist, the more
245
chance evas has of merging draw commands that have the same modes,
246
texture source etc., but the more overhead there is in finding a
247
pipeline slot for the draw command to merge into, so there is a
248
compromise here between spare cpu resources and gpu pipelining. unset
249
this environment variable to let evas use it's default value.
251
export EVAS_GL_ATLAS_ALLOC_SIZE=N
252
set the size (width in pixels) of the evas texture atlas strips that
253
are allocated. the default is 1024. unset this to let evas use its
254
default. if this value is larger than the maximum texture size, then it
255
is limited to that maximum size internally anyway. evas tries to
256
store images together in "atlases". these are large single textures
257
that contain multiple images within the same texture. to do this evas
258
allocates a "wide strip" of pixels (that is a certain height) and then
259
tries to fit all images loaded that need textures into an existing
260
atlas texture before allocating a new one. evas tries a best fit
261
policy to avoid too much wasting of texture memory. texture atlas
262
textures are always allocated to be EVAS_GL_ATLAS_ALLOC_SIZE width,
263
and a multiple of EVAS_GL_ATLAS_SLOT_SIZE pixels high (if possible -
264
power of 2 limits are enforced if required).
266
export EVAS_GL_ATLAS_ALLOC_ALPHA_SIZE=N
267
this is exactly the same as EVAS_GL_ATLAS_ALLOC_SIZE, but for
268
"alpha" textures (texture used for font glyph data). it works exactly
269
the same way as for images, but per font glyph being put in an atlas
270
slot. the default value for this is 4096.
272
export EVAS_GL_ATLAS_MAX_W=N
273
set this to limit the maximum image size (width) that will be
274
allowed to go into a texture atlas. if an image exceeds this size, it
275
gets allocated its own separate individual texture (this is to help
276
minimize fragmentation). the default value for this is 512. if you set
277
this environment variable it will be overridden by the value it is set
278
to. the maximum value possible here is 512. you may set it to a
281
export EVAS_GL_ATLAS_MAX_H=N
282
this is the same as EVAS_GL_ATLAS_MAX_W, but sets the maximum height
283
of an image that is allowed into an atlas texture.
285
export EVAS_GL_ATLAS_SLOT_SIZE=N
286
this sets the height granularity for atlas strips. the default (and
287
minimum) value is 16. this means texture atlas strips are always a
288
multiple of 16 pixels high (16, 32, 48, 64, etc...). this allows you
289
to change the granularity to another value to avoid having more
290
textures allocated or try and consolidate allocations into fewer atlas
293
export EVAS_GL_NO_MAP_IMAGE_SEC=1
294
if this environment variable is set, it disabled support for the SEC
295
map image extension (a zero copy direct-texture access extension that
296
removes texture upload overhead). if you have problems with dynamic
297
evas images, and this is detected by evas (see EVAS_GL_INFO above to
298
find out if its detected), then setting this will allow it to be
299
forcibly disabled. unset it to allow auto-detection to keep working.
302
--enable-gl-flavor-gles
304
this enables the opengl-es 2.0 flavor of opengl (as opposed to desktop
305
opengl) when building evas's gl-x11 engine above. this will be needed
306
if you are building evas for opengl-es 2.0 enabled embedded devices.
307
evas works on several opengl-es 2.0 compliant gpu's and gains more
308
testing and optimization regularly. it is also capable of
309
texture-from-pixmap support in opengl-es like it is in desktop opengl.
312
--enable-gles-variety-sgx
314
this tells evas that you are building the gl-es engine for a
315
shader-compiler "sgx style" opengl-es 2.0 implementation. this is
316
where the shader compiler is provided at runtime and can accept the
317
shader glsl source and work
320
--enable-gles-variety-s3c6410
322
this tells evas that you have an s3c6410 style opengl-es
323
implementation that has an offline shader compiler and that needs
324
pre-compiled shader binaries (provided with evas). this has not been
325
tested in quite a while as the drivers and environment for this system
329
--enable-software-gdi[=static]
331
windows gdi based engine for evas
334
--enable-software-ddraw[=static]
336
windows direct-draw engine for evas
339
--enable-direct3d[=static]
341
evas direct3d engine (experimental)
344
--enable-software-sdl[=static]
346
this is the sdl engine that uses sdl library (http://www.libsdl.org). This
347
library should work on many operating system. the buffer is
348
software-rendered with evas's default software rendering core.
351
--enable-gl-sdl[=static]
353
opengl (and opengl-es2.0) rendering engine that uses sdl as the front
354
end interface. see --enable-gl-x11 etc. for information.
356
------------------------------------------------------------------------------
360
this enabled the c code. you can actually build the code without the c
361
fallback code and only have the mmx routines for example. it is suggested to
362
always use this regardless unless you have some definite size issues with the
368
this enables the mmx optimized routines. this works for pentium, pentium2,
369
pentium3, pentium4, athlon and duron processors. it can get quite
370
considerable speedups, souse it if you can. ppc owners just have to live with
371
the c fallback functions unfortunately as no one has provided any ALTIVEC asm
372
routines yet. :) arm owners will also have to rely on the c fallback
373
routines as i haven't managed to come up with any arm assembly that actually
374
can beat the c code (when compiled with all optimizations) in speed.
379
this enables sse optimizations available in he pentium3 and 4 cpus (not
380
athlon and duron or pentium 2 or pentium cpu's). ppc owners just have to
381
live with the c fallback functions unfortunately as no one has provided any
382
ALTIVEC asm routines yet. :) arm owners will also have to rely on the c
383
fallback routines as i haven't managed to come up with any arm assembly that
384
actually can beat the c code (when compiled with all optimizations) in speed.
388
this enables sse3 optimizations available in the Intel Pentium4, Core, Xeon,
389
and Atom processors, as well as the AMD Athlon64, Phenom, Opteron, and Turion
395
This enables support for the Arm Cortex-A8 and later Neon register
396
set. In particular it will use neon optimized code for rotations and
397
drawing with the software engines. Open GL based renderers will gain
398
nothing from the use of neon.
400
To use neon with gcc-4.4 you need a post-2009 gcc and options
401
something like: -mcpu=cortex-a8 -mfloat-abi=softfp -mfpu=neon
402
Note that this slightly slows down non-optimized parts of evas but
403
the gains in drawing are more then worth it overall.
405
This is enabled by default, and turns off if a small test program is
408
Performance is at least 50%, and in some real world tests approaches
411
If you have any issues with neon, please report them to either the
412
edevel mailing list or Brett Nash <nash@nash.id.au>
415
------------------------------------------------------------------------------
417
--enable-image-loader-png[=static]
419
this enables the loader code that loads png files using libpng. there may be
420
call for embedded devices later that have custom written small image
421
loaders that uses less disk space than libpng to load custom format images.
422
for now this is the only loader so you may as well include it.
425
--enable-image-loader-jpeg[=static]
427
this enables the loader code that loads jpeg files using libjpeg. this
428
loader also supports load options to pre-scale jpeg images down to
429
provide much faster load times while also getting downscaling by 1/2,
430
1/4 or 1/8th the size in each dimension for "free". with an added
431
patch to libjpeg7, it can also fast-decode a specific region of a jpeg
432
file (without the patch it take a slow-path to do this).
435
--enable-image-loader-edb[=static]
437
edb image loader- can load images inside edb database files. not very
438
useful as edb itself is no longer used by enlightenment. may be
439
removed at some point, so unless you have a burning need for this,
440
don't use edb files to store image data and rely on this loader
443
--enable-image-loader-eet[=static]
445
loads image data from eet files. eet files are the backing for edje
446
storage, so this is needed for edje to work. it is very useful as it
447
can load an image from anywhere in the eet archive by key value so eet
448
files are like "zip" files where you can pack a whole lot of image and
449
other data together and just pick out the pieces you need at runtime.
450
requires the eet library.
453
--enable-image-loader-gif[=static]
455
gif image loader. gif is an obsolete format, but due to its longevity,
456
sitll has lots of existing data around.
458
NOTE: evas has no notion of time, thus animated gif file are not
462
--enable-image-loader-pmaps[=static]
464
ppm/pnm/pgm image loader that can load the "pnm" style image format.
465
not very common, but the files are simple raw RGB, greyscale image or
466
bitmap data in binary or ascii format
469
--enable-image-loader-svg[=static]
471
this loader can load svg files via esvg (thus it is a dependency). This
472
loader supports load options to set the dpi to decode the svg at etc. which
473
can then be used to create scalable images that scale to any size without
474
becoming blocky or blurry, if the source is an svg file.
476
Esvg can be found here:
478
http://code.google.com/p/enesim/
480
Install (in that order):
488
--enable-image-loader-tiff[=static]
490
this loader uses libtiff to load tiff image files
492
--enable-image-loader-webp[=static]
494
this loader uses libwebp to load webp image files
496
--enable-image-loader-xpm[=static]
498
this is an xpm format image loader. xpm format images are ascii files
499
that look like c/c++ source code that contain images. these files are
500
old-fashioned unix+x11 images you may encounter, but are inefficient
501
for storage and decoding and have been superseded by png files in
505
--enable-image-loader-bmp[=static]
507
this enables the bmp image format loader. note that there seems to be
508
a disagreement on 32bit bmp format images where alpha channels are
509
concerned and you may run into issues with bmps generated by the gimp
510
that have alpha channels. there is a problem where they don't seem to
514
--enable-image-loader-tga[=static]
516
this loader load tga format files. these files are very old-fashioned
517
but found often in the 3d graphics world.
520
--enable-image-loader-generic[=static]
522
this loader will execute a given binary to decode an image and read
523
the resulting image data via a shared memory segment, a mmaped file or
524
stdout. it uses the command-line to pass the filename and any load
525
parameters, and reads stdout from the loader binary to get metadata like
526
width, height, alpha channel flag and location of pixel data. this
527
loader has no dependencies as the binaries run are to be found in
528
PREIFX/lib/evas/utils and are named evas_image_loader.EXTENSION where
529
.EXTENSION is replaced by the filename extension to be decoded. if
530
this binary does not exist then evas_image_loader (with no extension) is
531
tried as a last fallback allowing it to handle "all cases".
533
since this loader doesn't use any libraires, it relies on runtime
534
dependencies and executables existing in the utils directory. note that
535
images loaded via this mechanism will have slower load times due to the
536
overhead of execution of another binary, but any instability in the
537
loaders themselves will not affect the application using evas.
539
this also means that licenses such as GPL for the binaries in this
540
utils directory do not affect evas and the applications or libraries
543
there is a separately released evas_generic_loaders package which
544
builds stand-alone binaries that can do this style of decoding for for
545
evas. this package currently handles XCF, PDF, PS, RAW, SVG (via
546
librsvg) and video formats (via gstreamer).
549
------------------------------------------------------------------------------
551
--enable-font-loader-eet[=static]
553
this loader can load font (ttf) files directly from eet archives like
554
the eet image loader. requires the eet library
557
------------------------------------------------------------------------------
561
this enables an optimized yuv (yv12 601 colorspace) to ARGB32
565
--enable-convert-16-rgb-565
567
the most common converter you'll want for 16bpp. this means 5 bits for red,
568
6 bits for green and 5 bits for blue are used.
571
--enable-convert-16-rgb-555
573
this is a converter for what many people know as "15 bit" color. you might
574
want to enable this for X output as it used to be common to find many cards
578
--enable-convert-16-rgb-444
580
this converter outputs to 12bit packed (int 16 bit WORDS).
583
--enable-convert-16-rgb-ipq
585
this converter was written specifically for the ipaq (and may apply to
586
similarly configured devices) because it lies about its screen depth. it
587
says it is 16bit 565 (that means 5 upper bits of the WORD are red, the next 6
588
bits are for green abd the next 5 for blue) but in fact only the upper 4
589
bits of each color component (red green and blue) are significant and work,
590
so effectively the display is 12 bits of color, not 16, but padded out to
591
fill 16bits, with unused bits in the color masks. X on the ipaq advertises
592
it as a full 16bpp 565 display (i can't remember what the linux framebuffer
593
advertised it as) and so many lumps of code can be fooled into rendering
594
data badly because they think the output will look as the expect. This
595
renderer assumes the upper 4 bits fo each color primitive only are
596
significant and renders accordingly. this produces nice quality images on
597
the ipaq and even still works in 16bpp 565 on your pc. it is highly
598
recommended to use this renderer if your target is an ipaq or your device
599
displays similar qualities of the ipaq for display purposes.
602
--enable-convert-16-rgb-rot-0
604
this enables the 16bpp converters to run with 0 degrees rotation - this is
605
normal display and you should really include this (though it is optional if you
606
only ever want to do portrait mode - perhaps like on an ipaq embedded device)
609
--enable-convert-16-rgb-rot-270
611
this enables the portrait mode (270 degree rotation) converters for 16bpp.
612
this is the standard display mode for things like pocketpc on the ipaq and
613
the zaurus etc. this is an optimized part of the rendering pipeline to allow
614
portrait display with a much lower overhead than doing it through X.
617
--enable-convert-16-rgb-rot-180
619
same as --enable-convert-16-rgb-rot-270 but for 180 degrees
622
--enable-convert-16-rgb-rot-90
624
same as --enable-convert-16-rgb-rot-270 but for 90 degrees
627
--enable-convert-24-rgb-888
629
this converts evas's 32bit ARGB to 24bit RGB packed format for output
633
--enable-convert-24-bgr-888
635
this converts evas's 32bit ARGB to 24bit packed BGR format for output
639
--enable-convert-32-rgb-8888
641
32bit RGB output conversion support. byteswapping compared to evas's
645
--enable-convert-32-bgr-8888
647
conversion (reduces to a memory copy) from evas's native colorspace to
648
the same color format.
651
--enable-convert-32-rgb-rot-0
653
copies without rotation evas's native image format
656
--enable-convert-32-rgb-rot-270
658
copies evas's native ARGB32 pixels but at a rotation of 270 degrees.
661
--enable-convert-32-rgb-rot-180
663
same as --enable-convert-32-rgb-rot-270 but for 180 degrees
666
--enable-convert-32-rgb-rot-90
668
same as --enable-convert-32-rgb-rot-270 but for 90 degrees
671
--enable-convert-24-rgb-ezx
673
a special colorspace handler for 18bit color packed into 24bit output
674
(where only 6 bits per r, g and b byte are used). the only known
675
platform that did this was the motorola esx based phones that used
676
qtopia originally and have open ezx ports for them.
679
--enable-convert-8-gry-1
681
enable 8bit gray to 1 bit black & white converter
684
--enable-convert-8-gry-16
686
8bit grey to 16 level grayscale converter
689
--enable-convert-8-grayscale-64
691
8bit grey to 64 level grayscale converter
694
--enable-convert-8-rgb-332
696
enable converter from 32bit ARGB to 8bit color "332" colorspace (3bits
697
red, 3 bits green, 2 bits blue)
700
--enable-convert-8-rgb-666
702
enable converter from 32bit ARGB to 8bit color "216" "websafe"
703
colorspace (6 values for red, 6 for green and 6 for blue - 6x6x6 being
707
--enable-convert-8-rgb-232
709
same as convert-8-rgb-332 but 2 bits red, 3 green, 2 blue
712
--enable-convert-8-rgb-222
714
same as convert-8-rgb-332 but 2 bits red, 2 green, 2 blue
717
--enable-convert-8-rgb-221
719
same as convert-8-rgb-332 but 2 bits red, 2 green, 1 blue
722
--enable-convert-8-rgb-121
724
same as convert-8-rgb-332 but 1 bit red, 2 green, 1 blue
727
--enable-convert-8-rgb-111
729
same as convert-8-rgb-332 but 1 bit red, 1 green, 1 blue. this is the
730
lowest sized colorspace supported for rgb (3bits, 8 color).
733
------------------------------------------------------------------------------
737
this enables pthread support in evas so multiple threads may run
738
internally for parallel rendering, loading etc.
743
this provides the ability for evas to have an asynchronous event
744
notification pipe to provide events when background threads are done
745
with tasks, like pre-loading image files
748
--enable-async-preload
750
evas can load images (preload) in the background using a thread
751
if you ask it to, and provide events when done. this goes hand-in-hand
752
with --enable-pthreads and --enable-async-events. you really want all
756
--enable-pipe-render **NOT ON BY DEFAULT DUE TO DUBIOUS IMPROVEMENTS**
758
this enables a multiple-thread renderer that divides the rendering
759
into N regions (1 per core) to speed up rendering in software when you
760
have multiple cpu cores.
765
this enables fontconfig support for loading font files by using
766
generic fontconfig font names and styles. you really should use this
767
by default on any linux/unix platform for universal font support.
772
this enables support for the fribidi library to have right to left and
773
left to right font rendering so languges such as arabic, hebrew and
774
other "RTL" langauges display properly.
779
this enables support for the harfbuzz shaping library for complex
780
shaping support in arabic, hindi and other similar languages.
784
this enables support of complex line breaking rules using liblinebreak.
786
--enable-evas-magic-debug
788
this allows you to enable and disable evas's extra magic number
789
checks. these allow better stability with runtime object magic
790
"number" checks to make sure you are accessing a real object in memory
791
of the right type, and will avoid doing "bad things" if they detect
792
the wrong object type being passed in. if you are absolutely sure your
793
system has no bugs in accessing objects of the wrong type with the
794
wrong calls, you can gain some small performance by disabling this.
797
------------------------------------------------------------------------------
800
For the arm optimizations you want to try:
801
export CFLAGS="-O2 -march=armv5te -mcpu=arm1136jf-s -fomit-frame-pointer"
803
To enable the async renderer compile with:
804
--enable-async-render
805
and also runtime set this environment variable:
806
export EVAS_RENDER_MODE=non-blocking
808
For compilation with MinGW, fnmatch.h is probably missing. That file can be
810
http://www.koders.com/c/fid2B518462CB1EED3D4E31E271DB83CD1582F6EEBE.aspx
811
It should be installed in the mingw include directory.