1 files changed, 0 insertions, 867 deletions

diff --git a/libraries/evas/README b/libraries/evas/README
deleted file mode 100644
index e8da700..0000000
--- a/libraries/evas/README
+++ /dev/null
@@ -1,867 +0,0 @@
-Evas 1.2.0
-
-******************************************************************************
-
- FOR ANY ISSUES PLEASE EMAIL:
- enlightenment-devel@lists.sourceforge.net
-
-******************************************************************************
-
-Requirements:
--------------
-
-Must:
-  libc
-  eina (1.1.0 or better)
-  freetype (2.1.9 or better)
-
-Recommended:
-  libX11 + libXext + libXrender
-  OpenGL2.0 or OpenGL-ES 2.0
-  fontconfig
-  libpng
-  libjpeg (6.0 or better)
-  eet (1.5.0 or better)
-  fribidi
-  harfbuzz
-  liblinebreak
-
-Optional:
-  XCB SDL OpenGL librsvg libtiff libgif edb DirectFB evas_generic_loaders
-
-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). You 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 really need the speed for low depth
-  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:
-
-All engines can be compiled statically inside libevas.so in order to
-reduce runtime time at dynamically loaded modules. All you have to do
-is to enable your chosen modules with "=static" suffix. If they depend
-on software_generic (most do), you need that as well. Examples:
-
-  ./configure --enable-static-software-generic --enable-software-xlib=static
-
-
---enable-software-xlib[=static]
-
-this enables the software x11 rendering engine that renders to X drawable
-targets using highly optimized software routines. there is no hardware
-assist here. this engine requires X11 to be installed to build (and run).
-This is a good generic engine that is fast and can run in X for good
-development and debugging purposes.
-
-
---enable-software-xcb[=static]
-
-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. It is not
-recommended to use this as it's experimental and will create problems
-with both ecore_evas and enlightenment itself.
-
-
---enable-fb[=static]
-
-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-directfb[=static]
-
-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[=static]
-
-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-gl-x11[=static]
-
-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.
-
-some environment variables that control the opengl engine are as
-follows:
-
-export EVAS_GL_INFO=1
-  set this environment variable to enable output of opengl information
-such as vendor, version, extensions, maximum texture size etc. unset
-the environment variable to make the output quiet again.
-
-export EVAS_GL_MEMINFO=1
-  set this environment variable to enable dumping of debug output
-whenever textures are allocated or freed, giving the number of
-textures of each time and how many kb worth of pixel data are
-allocated for the textures. unset it again to stop this dumping of
-information.
-
-export EVAS_GL_WIN_RESURF=1
-  set this environment variable to enable the gl engine to try and
-ddelete the window surface, if it can, when told to "dump resources"
-to save memory, and re-allocate it when needed (when rendering
-occurs). unset it to not have this behavior.
-
-export EVAS_GL_CUTOUT_MAX=N
-  set this environment variable to the maximum number of rectangles
-applied to a rendering of a primitive that "cut away" parts of that
-primitive to render to avoid overdraw. default is 512. unset it to use
-defaults, otherwise set N to the max value desired or to -1 for
-"unlimited rectangles".
-
-export EVAS_GL_PIPES_MAX=N
-  set the maximum number of parallel pending pipelines to N. the
-default number is 32 (except on tegra2 where is it 1). evas keeps 1 (or more)
-pipelines of gl draw commands in parallel at any time, to allow for merging
-of non-overlapping draw commands to avoid texture binding and context
-changes which allows for more streamlining of the draw arrays that are
-filled and passed to gl per frame. the more pipelines exist, the more
-chance evas has of merging draw commands that have the same modes,
-texture source etc., but the more overhead there is in finding a
-pipeline slot for the draw command to merge into, so there is a
-compromise here between spare cpu resources and gpu pipelining. unset
-this environment variable to let evas use it's default value.
-
-export EVAS_GL_ATLAS_ALLOC_SIZE=N
-  set the size (width in pixels) of the evas texture atlas strips that
-are allocated. the default is 1024. unset this to let evas use its
-default. if this value is larger than the maximum texture size, then it
-is limited to that maximum size internally anyway. evas tries to
-store images together in "atlases". these are large single textures
-that contain multiple images within the same texture. to do this evas
-allocates a "wide strip" of pixels (that is a certain height) and then
-tries to fit all images loaded that need textures into an existing
-atlas texture before allocating a new one. evas tries a best fit
-policy to avoid too much wasting of texture memory. texture atlas
-textures are always allocated to be EVAS_GL_ATLAS_ALLOC_SIZE width,
-and a multiple of EVAS_GL_ATLAS_SLOT_SIZE pixels high (if possible -
-power of 2 limits are enforced if required).
-
-export EVAS_GL_ATLAS_ALLOC_ALPHA_SIZE=N
-  this is exactly the same as EVAS_GL_ATLAS_ALLOC_SIZE, but for
-"alpha" textures (texture used for font glyph data). it works exactly
-the same way as for images, but per font glyph being put in an atlas
-slot. the default value for this is 4096.
-
-export EVAS_GL_ATLAS_MAX_W=N
-  set this to limit the maximum image size (width) that will be
-allowed to go into a texture atlas. if an image exceeds this size, it
-gets allocated its own separate individual texture (this is to help
-minimize fragmentation). the default value for this is 512. if you set
-this environment variable it will be overridden by the value it is set
-to. the maximum value possible here is 512. you may set it to a
-smaller value.
-
-export EVAS_GL_ATLAS_MAX_H=N
-  this is the same as EVAS_GL_ATLAS_MAX_W, but sets the maximum height
-of an image that is allowed into an atlas texture.
-
-export EVAS_GL_ATLAS_SLOT_SIZE=N
-  this sets the height granularity for atlas strips. the default (and
-minimum) value is 16. this means texture atlas strips are always a
-multiple of 16 pixels high (16, 32, 48, 64, etc...). this allows you
-to change the granularity to another value to avoid having more
-textures allocated or try and consolidate allocations into fewer atlas
-strips etc.
-
-export EVAS_GL_NO_MAP_IMAGE_SEC=1
-  if this environment variable is set, it disabled support for the SEC
-map image extension (a zero copy direct-texture access extension that
-removes texture upload overhead). if you have problems with dynamic
-evas images, and this is detected by evas (see EVAS_GL_INFO above to
-find out if its detected), then setting this will allow it to be
-forcibly disabled. unset it to allow auto-detection to keep working.
-
-
---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[=static]
-
-windows gdi based engine for evas
-
-
---enable-software-ddraw[=static]
-
-windows direct-draw engine for evas
-
-
---enable-direct3d[=static]
-
-evas direct3d engine (experimental)
-
-
---enable-software-sdl[=static]
-
-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[=static]
-
-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[=static]
-
-8bit only rendering core. intended for greyscale output on things like
-e-paper or simplistic greyscale LCD devices which have no color, such
-as ebook readers.
-
-if compiling with =static suffix, then must
-"./configure --enable-static-software-8" as well.
-
-
---enable-software-16-x11[=static]
-
-16bit specific renderer. lower quality than the default. also limited
-in abilities (no support for smooth scale or transformations/map). in
-a state of disrepair. do not use unless your hardware is just 16bpp
-and very limited in CPU and memory.
-
-if compiling with =static suffix, then must
-"./configure  --enable-static-software-16" as well.
-
-
---enable-software-16-ddraw[=static]
-
-16bit renderer for direct-draw. same as software-16-x11 - don't use.
-in disrepair.
-
-if compiling with =static suffix, then must
-"./configure --enable-static-software-16" as well.
-
-
---enable-software-16-wince[=static]
-
-same as software-16-ddraw but for windows-ce. in disrepair. don't use.
-
-if compiling with =static suffix, then must
-"./configure --enable-static-software-16" as well.
-
-
-------------------------------------------------------------------------------
-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-sse3
-
-this enables sse3 optimizations available in the Intel Pentium4, Core, Xeon,
-and Atom processors, as well as the AMD Athlon64, Phenom, Opteron, and Turion
-processors.
-
-
---enable-cpu-neon
-
-This enables support for the Arm Cortex-A8 and later Neon register
-set.  In particular it will use neon optimized 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-optimized 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.au>
-
-
-------------------------------------------------------------------------------
-IMAGE LOADERS:
---enable-image-loader-png[=static]
-
-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[=static]
-
-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[=static]
-
-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[=static]
-
-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[=static]
-
-gif image loader. gif is an obsolete format, but due to its longevity,
-sitll has lots of existing data around.
-
-NOTE: evas has no notion of time, thus animated gif file are not
-supported!
-
-
---enable-image-loader-pmaps[=static]
-
-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[=static]
-
-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[=static]
-
-this loader uses libtiff to load tiff image files
-
-
---enable-image-loader-xpm[=static]
-
-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[=static]
-
-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[=static]
-
-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[=static]
-
-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 is buggy! it will likely cause crashes and rendering corruption.
-Do not enable it unless you plan to actually work on it. 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 **DISABLED DUE TO BUGS**
-
-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).  If it detects a GL
-backend is in use, it disables itself.
-
-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 **DISABLED DUE TO BUGS**
-
-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 size 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 one or both of word or metric caching,
-depending on your engine use.  If you are only using software, enable word
-caching (and neon on arm if you can), for GL, turn on metric caching.
-A simple solution is enable both, and let the engine sort it out at run time.
-
-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-harfbuzz
-
-this enables support for the harfbuzz shaping library for complex
-shaping support in arabic, hindi and other similar languages.
-
---enable-liblinebreak
-
-this enables support of complex line breaking rules using liblinebreak.
-
---enable-evas-magic-debug
-
-this allows you 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.
-