Subject: [E-devel] [PATCH][RESEND][Evas] WebP image loader
This patch adds a WebP image loader to Evas. No saver,
no animation support for now, just loader. Tested with
the libwebp-0.2.0 only, but should work fine with older
versions.
SVN revision: 75951
now seriously...
Introducing Cache Serve 2.
This cache server will initially load images for clients connected to
it. It starts slave processes to load these images, and share the loaded
images through shm with the clients. All the connection done between
clients and the server goes through sockets.
The cserve2 build option is turned on by default, while the old cserve
was disabled, but in order to make clients use it, the environment
variable EVAS_CSERVE2 must be set, and a server must be running.
Clients will try to find the socket on a specified location using the
environment variable EVAS_CSERVE2_SOCKET. If it's not defined, then the
XDG_RUNTIME_DIR path should be used, and finally HOME, TMPDIR and /tmp.
SVN revision: 70699
Subject: RE: [E-devel] [Patch] Animation gif feature patch
Animated gif suport in evas and api's to handle animated images and
frame flipping. from jy.
SVN revision: 62331
This functions let you check if a file could be opened by
Evas_Object_Image. It is threadsafe, and you should use it
from another thread as often as possible :-)
SVN revision: 59872
more. making a loader is a matter of a binary of a specific name and
evas passes certain input on the cmd-line and your binary produces
output on stdout (and also optionally additionally in a shm or tmp
file).
SVN revision: 58914
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
* Remove vim modelines:
find . -name '*.[chx]' -exec sed -i '/\/\*$/ {N;N;/ \* vim:ts/d}' \{\} \;
find . -name '*.[chx]' -exec sed -i '/\/[\*\/] *vim:/d' \{\} \;
* Remove leading blank lines:
find . -name '*.[cxh]' -exec sed -i '/./,$!d'
If you use vim, use this in your .vimrc:
set ts=8 sw=3 sts=8 expandtab cino=>5n-3f0^-2{2(0W1st0
SVN revision: 50816
imlib2 bmp loader, but it was imcomplete compared to the bmp
standards, so i actually ended up reading the file format definitions
on line i could find and using lots of test images... wrote a new one.
you can at least view bmp files now. note - i found 1 bmp file that
claims to have an alpha channel (amask is non-empty) and then proceeds
to provide an image with pixels - all alpha 0. so its transparent when
it shouldnt be. beats me but looks like a broken bmp file to me when
it compes to specs.
SVN revision: 49324
Evas image load was always reporint "generic" error, since it was
disconnected from actual loader modules.
This commit will break the module loader API (as it's restricted to
inside Evas, this should be no problem). The return was turned into
"Eina_Bool" for clarity, while an extra "int *error" is responsible to
report errors. This approach was choosen to force compiler warnings
and to try avoid mistakes as EINA_FALSE == EVAS_LOAD_ERROR_NONE and
thus we'd get opposite behavior if something slips.
Most loaders play well, except by eet that does not provide means to
know if the file open failed due missing file, incorrect format or
corrupted file :-(
Please report any issues. I added eina_log debugging to loader
functions, just run your Evas application as:
EINA_LOG_LEVELS=evas_main:4 your_app
SVN revision: 44666
be way too big to ever allocate. probably code can do with other fixes too.
also make jpeg loader rudametarily understand load regions. very brute-force.
but enough for just this moment to do testing.
SVN revision: 42507
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
Image_Entry flag structure. This fix a bug with 16 bpp software engine.
* Change image loader module API to take any Image_Entry. Same goes
for evas_common_image_premul and evas_common_image_set_alpha_sparse.
* Use new eet API: eet_data_image_read_to_surface.
SVN revision: 34728