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
This patch fixes the problem with bitfield of signed types (ie: char),
where the bit would be used for the signal, so 1 is considered -0 and
thus 0.
Move all the single bit fields to Evas_Bool, making it clear and also
avoiding these problems since Evas_Bool is unsigned char.
SVN revision: 34631
* Allow Windows Mobile to correctly load dll's
* Use correct scheme for EAPI on Windows and include config.h when necessary
* add -mwin32 to compiler flags when compiling with cegcc
SVN revision: 34024
tuned for best performance on my core2 duo desktop - for now. will check
more. also make the yuv colorspace code be a bit more robust and fix leak in
gl engine with shaders.
SVN revision: 30192
in evas_gl_texture.c i have a frag shader, and it tries to use a set of 3
textures that act as the yuv planes, BUT the u and v textures (Utex and Vtex)
are simply getting values from the Ytex - regardless of what i try. grrr.
what's up with that?
SVN revision: 27495
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
renderer gets threaded). if i thread at the simplest levels (low down in for
example the image scaler code - one of the most expensvie gfx routnes) on an
actual dual core system - performance drops by 40%. this just doesn't work
well at that level. thread creates and joins per render op are just a bad
thing (tm) :) so this really needs to go in much higher up and that presents
problems. :( i will need to clearly define entry and exit points to and from
threaded space (and thus all the locks) - remove all nested calls (where
internal code goes thru the same entry/exit points traditionally so it
deadlocks itself).. anyway - this here has all that code stripepd out i
played with - it is just the autofoo and build stuff so we can turn on/off
thread support at will in the build.
SVN revision: 26817
doursse
Cedric BAIL
Gustavo Sverzut Barbieri
Carsten Haitzler
tilman
Sebastian Dransfeld