We don't use this cache with cserve2, so it makes no sense to keep async
preload disabled. When not using the cserve2, even if built with that
option, it will support preload with no side effects.
SVN revision: 73422
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
NOTE: This should be part of evas_render itself and not
delegated to the engine. So cleaning things to make it easier
during evas_render rewrite.
SVN revision: 70503
if file was chaned by somebody, it was added to dirty list during cache request.
currently this dirty image added to cache->dirty list and never freed until image shutdown.
but dirty image of chaned file never used so add delete code for memory efficiency.
and fix bad indentation.
SVN revision: 67604
We only check the value of references if EVAS_CSERVE isn't defined, so
no need to define it or assign it if EVAS_CSERVE isn't defined.
SVN revision: 67304
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
#0 0xb7e92786 in evas_cache_image_flush (cache=0x0) at evas_cache_image.c:1353
#1 0xb7e9192e in evas_cache_image_drop (im=0xb6aa4d38) at evas_cache_image.c:913
#2 0xb7ee3d8b in eng_image_free (data=0xb6a020c0, image=0xb6aa4d38) at evas_engine.c:383
#3 0xb7e4b8e6 in evas_object_image_free (obj=0xb7517178) at evas_object_image.c:2478
#4 0xb7e4f403 in evas_object_free (obj=0xb7517178, clean_layer=0) at evas_object_main.c:45
#5 0xb7e41c95 in evas_layer_free_objects (lay=0xb6a5d8b0) at evas_layer.c:80
#6 0xb7e42656 in evas_free (e=0xb6a98cd8) at evas_main.c:204
#7 0xb7f27ad3 in _ecore_evas_free (ee=0xb6ab18e8) at ecore_evas.c:2822
#8 0xb7f24161 in ecore_evas_free (ee=0xb6ab18e8) at ecore_evas.c:839
#9 0xb7df2f7f in _deferred_ecore_evas_free (data=0xb6ab18e8) at elm_win.c:477
#10 0x4b0fd858 in _ecore_job_event_handler (data=0x0, type=14, ev=0xb6a99c58) at ecore_job.c:131
#11 0x4b0f907e in _ecore_event_call () at ecore_events.c:693
#12 0x4b0ff93e in _ecore_main_loop_iterate_internal (once_only=0) at ecore_main.c:1750
#13 0x4b0fe195 in ecore_main_loop_begin () at ecore_main.c:848
SVN revision: 61736
Only call eina_threads_shutdown when thread are dead and not before.
Release and destroy thread lock before calling evas_async_events_process
as you should never have a lock taken in the main loop when calling it.
SVN revision: 59119
etc. etc. in corner-cases. it also re-factors the image cache code to
be much more manageable and understandable with cache/list management
doing the right thing in the internal calls.
SVN revision: 58779
for client apps that tried to be efficient with preloads to adapt
when the preloaded data is taken away from them. this allows it.
missing callback api bug fix.
SVN revision: 55745
(scalecaches) are flushed which can cause a hang until all data is
"loaded back in" again. it's a bit of a doosey actually and so isn't
fixed here.
SVN revision: 55551
There is no meaning in negative values for image loading, marking as
dirty or size, so image internals (cache, entry) were changed to
unsigned, reducing possible errors, particularly with overflow.
engines were converted to the new way, but any 3rd party modules will
still work as they should be using values >= 0 only anyway.
please review.
new cases introduced by "comparison between signed and unsigned" were
fixed in the modules that used cache_entry or Image_Entry dimensions.
SVN revision: 52428
Assert cache->usage never becomes negative as was occurring before the
fix in r52149.
Just in time, the fix in r52149 was made by Ulisses, not me.
SVN revision: 52190
Memory usage was not accounted right because
cache->func.mem_size_get(ie) returns 0 when called after
cache->func.destructor(ie). Thus the total memory used, kept on
cache->usage, is never decremented in _evas_cache_image_remove_activ()
This implies that cache->usage will keep growing and eventually it will
overflow, becoming negative. So evas_cache_image_flush() will not do its
job because cache->limit (assumed to be positive) will not be less than
cache->usage anymore. So the total memory allocated will start to grow
and the limit won't be respected.
Strictly speaking, it's not a leak, since all the memory will be
eventually freed when evas shutdown is called, but the program might be
killed by over allocating memory. This is caught by valgrind with the
massif tool. The graphic below shows that in the end a huge memory amount
is allocated. This is the moment when cache->usage became negative.
MB
26.04^ #
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| #::::
| :::::::::::::::::@@:::::::::@:::@::::::@::::::::::::::::::::::::::#::::
| : ::: ::: ::: :::@ :: ::: : @:: @:: :::@: :: ::: : : :: :: : ::: :#::::
0 +----------------------------------------------------------------------->Gi
0 54.83
This patch is a one line fix, which swaps the calls to
_evas_cache_image_remove_activ() and cache->func.destructor() making
cache->limit to be respected.
SVN revision: 52149
The offending projects were:
E16/e/src/backgrounds.c | 10 ++++------
PROTO/eon/src/lib/layout/eon_stack.c | 4 +---
ecore/src/lib/ecore_win32/ecore_win32.c | 3 +--
ecore/src/lib/ecore_wince/ecore_wince.c | 3 +--
edje/src/lib/edje_edit.c | 3 +--
evas/src/lib/cache/evas_cache_image.c | 2 +-
exalt/src/lib/libexalt_private.c | 2 +-
This patch assumes code in these places were insane and the fix is to remove
one condition check. Most likely this is not true, but there's no automatic fix
for that.
Looking at the patch, it seems that some places should use "x" and "y" vars but
used just one of them and therefore they were caught by coccinelle.
SVN revision: 51666
Revert previous patch generated by badnull.cocci script, and apply the new one.
The main difference is that assert and assert-like functions are not touched
anymore.
SVN revision: 51650
Apply badzero.cocci, badnull.coci and badnull2.cocci
This should convert all cases where there's a comparison to NULL to simpler
forms. This patch applies the following transformations:
code before patch ||code after patch
===============================================================
return a == NULL; return !a;
return a != NULL; return !!a;
func(a == NULL); func(!a);
func(a != NULL); func(!!a);
b = a == NULL; b = !a;
b = a != NULL; b = !!a;
b = a == NULL ? c : d; b = !a ? c : d;
b = a != NULL ? c : d; b = a ? c : d;
other cases:
a == NULL !a
a != NULL a
SVN revision: 51487
Rafael Antognolli
Iván Briano
Cedric BAIL
Carsten Haitzler
Jiyoun Park
Sebastian Dransfeld
Vincent Torri
Jiyoun Park
Mike Blumenkrantz
Lucas De Marchi
Christopher Michael
Gustavo Sverzut Barbieri