This commit moves Evas.h contents a lot, but it should not change code
(some conts were added, some function attributes were changed).
The purpose of such is to define the order that doxygen show modules
in its documentation.
I also splitted documentation a bit more, and added a src/examples to
list useful example code. Right now it is just a pure-evas
draw-and-save using buffer engine.
NOTE: there is lots to document, and the @todo list is quite long but
I guess lots of things there were done already. Raster, could
you review this list?
SVN revision: 47308
1. the concept of callbacks for a canvas as a whole. add/ del/ del_full these
2. focus in+out events for the canvas as a whole - can help solve some issues
with inoput methods + ecore-imf + entries (like edje_entry)
3. add callabcks to be called before/after flush of display.
SVN revision: 45761
This code should be cleaner and easier to understand. It also provides
the ability to spread image decompression on all CPU core. I currently
set it to the exact number of CPU core you have in your machine, if you
find case where it slow down your EFL apps too much, we can reduce this
to give at least one core to evas.
All previous bugs related with async preload are gone, hopefully no
new one are in. Please report any problem with backtrace to me.
SVN revision: 44537
also rename evas_layer_free() to evas_layer_free_objects() as what it
do now, make _evas_layer_free() as static and use it both cases.
SVN revision: 41123
the parent.
When we insert object inside a smart object, they could be attached to
another layer. As long as ref counting work, nothing wrong will happen.
But during destruction of an Evas, we were just looping over all layers,
destroying each of them, without checking for refcounting. This could
cause SEGV.
This patch introduce a third loop for wiping out all layers after
destroying all Evas_Object. So no more SEGV, and no performance
regression.
Note: Do not rely on evas_object_layer_get on smart object's child, it
could give you the wrong answer.
SVN revision: 41046
is it ok?
1. it can be --disabled in evas's configure, but i think it works WITHOUT
disabling it (runtime) as it falls back to the old way of loading
2. it may cause build problems on some platforms - without it being enabled
we won't find out, so enable.
3. it needs enabling runtime to make use of it so it should be safe for now
until you enable it.
what is it?
it is a SHARED cache server - that means images loaded are loaded BY the
cache server (not by the actual process using evas). images are shared via
shared memory segments (shm_open + mmap). this means only 1 copy is in all
ram at any time - no matter how many processes need it , and its only loaded
once. also if another app has already loaded the same data - and its in the
cache or active hash, then another process needing the same stuff will avoid
the loads as it will just get instant replies from the cache of "image already
there". as it runs in its own process it can also time-out images from the
cache too.
right now you enable it by doing 2 things
1. run evas_cserve (it has cmd-line options to configure cache etc.
2. export EVAS_CSERVE=1 (im the environment of apps that should use the cache
server).
it works (for me) without crashes or problems. except for the following:
1. preloading doesnt work so its disabled if cserve is enabled. thisis
because the load threads interfere withthe unix comms socket causing
problems. this need to really change and have the cserve know about/do
preload and let the select() on the evas async events fd listen for the
unsolicited reply "load done". but it's not broken - simple preloads are
syncronous and forced if cserve is enabled (at build time).
2. if cserve is killed/crashes every app using it will have a bad day. baaad
day. so dont do it. also cserve may be vulnerable to apps crashing on it - it
may also exit with sigpipe. this needs fixing.
3. if the apps load using relative paths - this will break as it doesnt
account for the CWD of the client currently. will be fixed.
4. no way to change cache config runtime (yet)
5. no way to get internal cache state (yet).
6. if cache server exist - it wont clean up the shmem file nodes in /dev/shm
- it will clean on restart (remove the old junk). this needs fixing.
if you fine other issues - let me know.
things for the future:
1. now its a separate server.. the server could do async http etc. loads too
2. as a server it could monitor history of usage of files and images and
auto-pre-load files it knows historically are loaded then whose data is
immediately accessed.
3. the same infra could be used to share font loads (freetype and/or
fontconfig data).
4. ultimately being able to share rendered font glyphs will help a lot too.
5. it could, on its own, monitor "free memory" and when free memory runs
load, reduce cache size dynamically. (improving low memory situations).
6. it should get a gui to query cache state/contents and display visually.
this would be awesome to have a list of thumbnails that show whats in the
cache, how many referencesa they have, last active timestamps etc.
blah blah.
please let me know if the build is broken asap though as i will vanish
offline for a bit in about 24hrs...
SVN revision: 40478
* evas_engine_info_set() returns now an int, to inform if
an error occured or not when setting the info of the engine.
* in the Evas_Func structure, the setup() method returns an int
* all the engines are updated
I'll fix ecore_evas and ewl later (the compilation is still fine).
Gustavo: should I add EINA_WARN_UNUSED_RESULT at the end of the
evas_engine_info_set() function ?
SVN revision: 39670
* group the want_* variables related to engines and loaders at the beginning
of configure.ac
* use -no-undefined directly instead of a flag checked wrt the host
* some clean up in Makefile.am files
Please report any problem
SVN revision: 37784
Draw back: When we are destroying an Evas canvas, we loose all cached font
that are not used anymore.
A correct fix would be to link Fndat to the Evas that provide and use them.
And only delete them when no more Evas reference them.
SVN revision: 37353
Some people is using it for some time now without problems, so I'm
adding it to SVN to get some broader use. Remember to recompile ALL
libraries that depend on Evas as it will change the
EVAS_SMART_CLASS_VERSION and old classes will fail to load.
This will also change Edje so it will postpone _edje_recalc() to
render time, calculate() callback, however some methods will force
early recalculation.
SVN revision: 35860
The engine is not entirely working right now. Recent devices which
supports the raw frame buffer should work though. But having it in
cvs will help me as I'm coding it most of the time "blindly" (no
device to test it)
* minor formatting in the top evel Makefile.am too
SVN revision: 34354