efl/legacy/evas
Carsten Haitzler 70013f2719 oops - minor logic hiccup - fixed.. also imlib2 fix for its load error
checking. missed this when adding db style (key in file) loading.


SVN revision: 4239
2001-02-17 20:39:53 +00:00
..
debian Debian packages may now be built from output of make dist and friends 2001-02-14 20:59:59 +00:00
doc clean up rastermanglish in the docs :) 2001-02-13 02:37:23 +00:00
src oops - minor logic hiccup - fixed.. also imlib2 fix for its load error 2001-02-17 20:39:53 +00:00
test This finishes up the complete rewrite of evas's backend engines to be cleaner, 2000-12-29 20:43:48 +00:00
.cvsignore Hush CVS :) 2000-11-15 20:14:05 +00:00
AUTHORS evas........ 2000-07-30 20:21:14 +00:00
COPYING evas........ 2000-07-30 20:21:14 +00:00
Makefile.am evas.m4 2001-01-25 21:56:04 +00:00
README More cleanups by srl <srl@penguinpowered.com>. 2000-12-30 07:19:54 +00:00
acconfig.h stubs for Xfree86 Render extension support. STUBS only now. will get filled in 2000-10-18 00:48:25 +00:00
autogen.sh evas........ 2000-07-30 20:21:14 +00:00
configure.in more optimizations in render function 2001-02-17 08:10:30 +00:00
evas-config.in evas.m4 2001-01-25 21:56:04 +00:00
evas.m4 evas.m4 2001-01-25 21:56:04 +00:00
evas.spec * fix requires for imlib2 to require 1.0.1 2001-01-07 22:02:31 +00:00

README

-------------------------------------------------------------------------------
                                E V A S - 0.0.3
-------------------------------------------------------------------------------

This is the ``E Canvas'' - a rip off of some of the other canvas's floating
about - Tk and gnome too. it's at the Xlib level. it's intended to be
accelerated by hardware or highly optimised software where possible. It is
intended to be simple and allow for the building of interfaces ontop of it.

if you got this from cvs do:
./autogen.sh

otherwise do:
./configure

then to compile:
make

if you wish to install (as root):
make install

in the test directory you will find a test program:

cd test
./evas_test

This is an overall demo of what Evas can do. You can select the rendering mode
on the left by simply clicking it. Just sit back, watch and relax.

There is also

./evas_test_old

this will by default try the software engine - if you don't have a fast cpu
it will be slow. You can try the other engines:
./evas_test_old -m x11
./evas_test_old -m soft -s 0
./evas_test_old -m hard

x11 is the X11 pixmap engine. -s 0 turns off ``dithering'' and smooth shading
for image objects here for better speed. hard is the opengl hardware 3D
engine. Note that if you do NOT have real hardware accelerated GL it will be
SLOOOOOOOOOOOOOW - VERY slow. Much slower than software. Also Mesa 3.2 and 
below has known bugs that cause a segv. It's been fixed in Mesa 3.3.

If evas didn't find OpenGL it will have built a software only engine so you
don't need to try hardware since this will fall back to software mode
automatically.

There is a new evas_test program being written too - it's in progress, so
wait for it to be complete.

-------------------------------------------------------------------------------
MORE DETAILED DESCRIPTION:
-------------------------------------------------------------------------------

Evas? Canvas? What? OK.. you're baffled as to what that stuff is. Time to
explain.

A canvas is a high-level rendering engine. Instead of a program having to
handle exposes or updates then redraw bit by bit (draw line, draw box, 
paste image etc.) after having figured out what has changed and what need to
be re-rendered - what data loaded in maps to what... then finally order the
draw in the right way to optimize it - a canvas provides a high-level API to
this kind of thing and handles all the smarts inside.

The result is an application creates an Evas & attaches that evas to a window.
Now it just creates objects - create an image object, a text object, a line
object, a rectangle object etc. It just moves and resizes these objects around
by calling routines in Evas - Evas handles redrawing, scaling, ordering the
draws to account for layers, clipping objects out that don't exist in the
visible Evas area etc. All the application need do is call evas_redraw when
it becomes idle to have the evas redraw what has changed.

This means less headache for the application programmer. Now why do this as
a whole new library? Well - because the library can render the Evas as fast
as possible. It uses Imlib2 to do the grunt work of loading images - and
beyond that it can currently use either imlib2, OpenGL or X11 to render to the
Evas - if you have decent hardware that's supported by OpenGL you will see
in the area of 10-50 times (in future even higher) speedups in rendering
using the GL backend instead of the Imlib2 one (even though Imlib2 is a
highly optimized software rendering engine). The good thing here is that the
application can choose what system to use. If that system isn't available or 
Evas didn't compile with it, it will fall back to the nearest approximation 
(it will ALWAYS have Imlib2 and X11 rendering backends - Imlib2 being able to
actually alpha blend, but X11 keeping the rendering server-side with pixmaps
and clip masks) so this means a highly optimized rendering subsystem to build
more complex things ontop of.

As it stands right now the API is still under construction - don't bank on it
remaining 100% stable. The backend of evas currently seems to have no bugs or
leaks that I know of, so feel free to punish it.