Patch from Thierry el Borgi with some rework of myself.
NOTE: I don't have much file to test, so if some don't
contact us with those file and we will fix the loader
if needed.
SVN revision: 58873
I don't know if this is useful to backport to stable branch, if you
think so please do it as I don't even have that checkout... svn is
annoying :-P
SVN revision: 58012
Subject: [E-devel] 8bpp xcb evas engine
Hi all,
I've implemented the 8bpp grayscale evas engine. It is based on the 16bpp
engine. It would be nice if someone could review the code and maybe commit
into svn. The patches against evas and ecore are attached.
SVN revision: 50560
* allow the build of evas without xlib installed (for OpenInkpot guys)
* add big fat warning when at least a module is linked statically (try it !)
more patches will follow now (ecore, e, rage and ewl)
I let pyton and c++ bindings maintainer to do the rename
SVN revision: 41329
automake was "smart enough" to include in DIST_SUBDIRS even when 'if'
clause didn't add it to SUBDIRS, that was causing modules like XPM be
added twice, resulting maintainer-clean to double-clean the directory
(one from src/modules/loaders and other from src/lib), failing on the
second time.
SVN revision: 41060
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
* 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
* formatting
* put WIN32_CFLAGS in AM_CFLAGS and not AM_CPPFLAGS, as it is where it belongs
* rename create_shared_lib to lt_no_undefined
* pass -Wl,--enable-auto-import to libtool when compiling with cegcc
* add files to EXTRA_DIST only when they are not in _SOURCES or _include_HEADERS (they
are added anyway)
SVN revision: 34353
* Allow Windows Mobile to correctly load dll's
* Use correct scheme for EAPI on Windows and include config.h when necessary
* add -mwin32 to compiler flags when compiling with cegcc
SVN revision: 34024
* use non deprecated version of AC_INIT and AM_INIT_AUTOMAKE
and check the required minimal versions.
* add bzipped distribution archive
* add AC_LIBTOOL_WIN32_DLL
* forbid libtool to check fortran
* compute libtool versioning from the version of the package
* pass the directories based on ${prefix} to the preoprocessor
with the -D option
* replace INCLUDES, wich is deprecated since 2001 by AM_CPPFLAGS
* remove useless -L flags in *_la_LDFLAGS
SVN revision: 32337
renderer gets threaded). if i thread at the simplest levels (low down in for
example the image scaler code - one of the most expensvie gfx routnes) on an
actual dual core system - performance drops by 40%. this just doesn't work
well at that level. thread creates and joins per render op are just a bad
thing (tm) :) so this really needs to go in much higher up and that presents
problems. :( i will need to clearly define entry and exit points to and from
threaded space (and thus all the locks) - remove all nested calls (where
internal code goes thru the same entry/exit points traditionally so it
deadlocks itself).. anyway - this here has all that code stripepd out i
played with - it is just the autofoo and build stuff so we can turn on/off
thread support at will in the build.
SVN revision: 26817
* This can be disabled with --enable-fontconfig=no
* Test in e17 with "enlightenment_remote -font-default-set title_bar Serif 12"
* This is just the beginning: TODO: style searching, language reorder bypass
SVN revision: 21394
Christopher Michael
Carsten Haitzler
Cedric BAIL
Youness Alaoui
Iván Briano
Vincent Torri
Gustavo Sverzut Barbieri
Tom Hacohen
Alexander Kerner
Lars Munch
doursse
tilman
stffrdhrn