crashes for me in expedite with 4 cores on x86 at random points. looks
like it's bitrotting. though it was relatively tentative to begin with.
SVN revision: 53856
it? and... lets not just throw pointer onto pipelines just for the
hell of it.. as like.. hmm the object owning the pointer might be
freed before pipelien finishes.. or hell. it might change pointer
contents? :) need to nwo dup bidi intl_props. probably a better plan..
tasn looking at you... is to fix up evas bidi utils and make the intl
props a new/free thing (and sharable eh?) with reference counts to
avoid dups (just ref up most of the time - and if u change, make a new
intl prop - dont change current one) etc. etc. for now dup - this
gives a perf hit tho. at least async rendering works now.
SVN revision: 51736
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
Added missing unicode & bidi opts to necessary places.
Fixes lots of compiler warnings.
NB - Not all engines tested. If you spot a problem wrt any specific
engine, please report it.
SVN revision: 50601
Changing textblock and text objects to work with Eina_Unicode instead of utf8 (internally, API remains intact).
Started relying on new fribidi 0.19.2 instead of the old fribidi.
A lot of fixes to the font engine.
Renaming of evas_common_font_utf8_* to evas_common_encoding_utf8_*
This relies on new Eina changes and types: Eina_Unicode, Eina_UStrbuf and Eina_UStringshare.
SVN revision: 50595
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
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
tyo fix up some of these breaks first and there isn't a lot of time devoted
to this. so revert this. it's in svn history so we can dig it out any time we
like.
SVN revision: 37453
1. nearest scaling is now broken - it's always linear interpolation. this
will lead to slowdowns. i need to fix this - a must.
2. i think it's time i put in a transformed image cache that can cache an
image object at a transform (and share it) automatically.
3. transforms in non-software-engines will not work - broken. need to at
least do xrender and gl engines.
any volunteers to help?
SVN revision: 37447
- some enignes break as they dont have the stubbed out functions, and
xrender/gl engines dont even implement the drawing and need to (but are
stubbed out).
SVN revision: 35677
pthread manual says it is safe to destroy them after they are used
with pthread_create: "If the attributes specified by attr are modified
later, the thread���s attributes shall not be affected."
SVN revision: 34937
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
1. disable viewports other than 1:1 at 0,0
2. remove output space coorsds for pointer.
3. remove geom caching
4. make threaded pipelined engine a runtime detect if u have > 1 cpu.
5. pthread build default if u have pthread.h and sched.h
SVN revision: 27131
sometimes slower)
2. --enable-pthreads will enable multi-threaded rendering (current support is
for up to 4 threads so if you have a new fanled quad core or dual cpu dual
core box or whatever you will in theory be able to max moe of its cpu grunt
with the software rendering engine. this can only be done because i added the
pipelines which means almsot entirely lock-free multithreading internally in
evas. the only locks are for fonts but with a little work i might be able to
remove some/most of those too)
for now pthreaded rendering likely will be linux only (it relies on sched.h
for setting scheduler params to force the slave threads to run on separate
cpu's as linux likes to keep them on the same cpu otherwise and thus we get
no speedups at all - only slowdowns).
aso note that it is a bit of a mixed bag. complex ops (like smooth scaling
with alpha blending) get speedups, but simple ops (like blits/fills) slow down.
this all neds examination and tweaking still - but it's a start.
SVN revision: 27098