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
More work, proudly supported by Samsung. Filters!
So now you can apply a whole host of cheesy visual effects to objects at
runtime. This is the first commit, there are a couple of more to come as I
tweak the filters, and fix blur with GL[1].
Please direct bugs to me nash@nash.id.au.
[1] You'd think shaders would be good at this.. but no, generic blur and GL
are like trying to get an apple product to work with Linux.
SVN revision: 58726
(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
Subject: evas scalecache 관련 패치 검토 요청
...
There is the report that evas_engine_dump() does not dump scalecache.
Knhoon made a patch for that.
SVN revision: 55178
* log domains in lower-case only please. let's make it a standard so
we don't have to look at the code everytime to figure out the name...
* logs do NOT require trailing newline (\n), it's automatic!
* do NOT add newline inside log messages!
* add gl_common logging.
NOTE: I tried to compile all modules, but there are clear broken
modules such as cairo and qtopia. Other modules like gl_sdl are
broken as they were not updated to new gl_common api (resize
method AFAIR).
SVN revision: 53174
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
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
* 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
Ouch, that was nasty! src/lib/cache/evas_cache_image.c was assuming
all Image_Entry were RGBA_Image (why?!?!?), thus doing the cast and
having mutexes and other to operate on garbage (possibly crashing due
segv). This happened to be the case with Soft16_Image used by
software_16 engines.
I'm not sure, but this may fix problems that people noticed with
async-render hanging their systems even if not explicitly enabled
during runtime.
I also found it quite strange the number of locks required by this
code! Clearly we could use macros to simplify and avoid bugs, but
maybe some atomic_inc/dec code should be used to remove half of the
mutexes in that code?
/me wonders what kinds of bug more we can expect from this code :-/
SVN revision: 50300
rendering. to turn on:
1.
configure with --enable-async-render
2.
export EVAS_RENDER_MODE=non-blocking
presto. necessitates some api swizzling (thus the expedite. ecore etc. changes)
the kind of results you get on a desktop:
http://www.rasterman.com/files/evas-async-vs-none.html
SVN revision: 49087
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
enabled. the blending is not working/complete. the neon for fills and copies
isnt actually faster though currently :(
2. scalecache infra - disabled for now. working on it.
SVN revision: 39723
* mainly unused parameters
* in src/lib/imaging/evas_imaging.c, set font to NULL
* in src/lib/canvas/evas_object_gradient.c, add unititialized member
there are a *lot* of reported warnings by llvm, i'll fix them later
there are also *lots* of unused parameters (compile evas with -W). I'll
fix them later too
SVN revision: 39172
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
totally done and may hand control back to a non rendering codepath - or
before u do any fp ops u are unsure of the cpu state beforehand. see the big
fat comment.
i was right. it was a missing emms.
SVN revision: 34707
2. free then malloc otherwise realloc might ALSO have to memcpy if it cant
resize the segment whihc means overhead we dont need/want.
SVN revision: 34441
Cedric BAIL
Jiyoun Park
Carsten Haitzler
Brett Nash
Vincent Torri
Gustavo Sverzut Barbieri
Lucas De Marchi
doursse