dunno why, but at least it does for me and some users at #e/#edevelop,
e17 freezes at start, so does canola and other evas apps, maybe due
64-bits? No time to investigate right now (at a conference).
SVN revision: 39738
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
* 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
let's stop replicating these macros over and over again, also flag
evas functions with attributes to help with optimizations.
TODO:
* move functions returning "int" as boolean to Eina_Bool
* move api entry to EINA_SAFETY_*
* document api
SVN revision: 39598
**** WARNING ****
E is bugged in some place, it does swallow object from another Evas in some place.
With this patch, it will abort sooner. If you find situation where it abort, please
report. This are nasty bug hidden in our code base. And yes, you will the white box
of death, this is expected.
SVN revision: 39528
uses the same mutex macros used by the mutex on font objects, so it makes it
a bit simpler. old code is commented out for reference.
SVN revision: 39458
* 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
2. make gl engine able to use cutouts - in some cases its faster, some
slower. it's a mixed bag. not sure what to make of it. it's #defined to be
disabled atm.
SVN revision: 39114
* evas/src/lib/engines/common/evas_font.h,
* evas/src/lib/engines/common/evas_font_draw.c,
* evas/src/lib/engines/common/evas_font_load.c,
* evas/src/lib/engines/common/evas_font_query.c: Add cache for font kerning.
This patch give something around 2% for all tests around text in expedite,
except for Textblock Intl where it give a 3 times boost.
Regarding text rendering speed, something is strange when used by evas_pipe.
All tests using Styles are around 40% faster without evas_pipe. 30% faster
for Text Change. But Text Basic 7% slower. So it should be possible to have
faster rendering when using evas_pipe for font rendering.
SVN revision: 38993
For some unknown reason evas was informing EVAS_CALLBACK_* even if the
original call did not changed the internal object state, that is, new
value is already equal to current value.
This is specially costly since Edje, Box, Table and possible other
layout engines will call evas_object_resize(), move(), show(), hide()
even if the state has not changed, assuming evas will ignore the call
(as it does). The real overhead might come if there are listeners
attached to these events, that in turn might do lots of other stuff,
leading to a torrent of useless calls.
I marked it for removal, please test it and uncomment '#define
CALLBACK_NOOPS' to get the old behavior back. It does seems to work
with e17 and edje_editor. If problems appear, let's try to fix the
real problem instead of getting this code back, it's a performance
penalty.
SVN revision: 38955
If one want to load image at a given height or width and the other
dimension should be large enough to make it possible, give -1 as the
other coordinate and this will happen.
SVN revision: 38845
we should just remove entries pending preload from the cache being
shutdown, not all of them.
this is untested as it is hard to force this situation, but should be
more correct than the previous.
SVN revision: 38747
before, when no more images were to be preloaded asynchronously, the
thread exited, but were not collected. This leads to a huge leak if
the process is doing aggressive use of image preloading (ie: photo
wall).
collecting dead threads in a proper way (read: without race
conditions) is a bit harder than keeping just one thread alive,
forever. As we do that for evas_pipe (the renderer), let's do the same
with preload and save code.
SVN revision: 38746
users of buffer engine (ie: e_thumb_main.c) were broken since when
they resize the canvas they would implicitly call engine->setup()
again, which would destroy output and create it again. However the
cache could be destroyed and images using it would be bogus.
This does not happen if the process have other cache users, but
e_thumb is just one canvas live at time.
By reordering, we have the cache reference to go to 2 and then back to
1, not destroying it.
SVN revision: 38739