Improvements: Now evas rendering loop is the one responsible to
initialize the surface to 0 correctly (taking into account surface
alpha and object opacity). This will reduce the number of memset
we do.
Note: Current software_x11 (xlib and xcb) are buggy. They are
copying too much data when the surface use a mask. That's why
two memset are left in their code. They could be removed, but
we should fix the surface we copy on change (look at mxob user
and evas_software_xlib_x_output_buffer_paste).
SVN revision: 41206
none (ie default) and the engines actually understand it and use it.
2. fixes to scalecache and cserver too. more toto's done and its now been
stress tested by me - and i think cserve is ready to go gold. just enable it
with export EVAS_CSERVE=1 in your env for any eflapps - and run evas_cserve
(cmd-line options avalable plus cmd-line tol to query settings change on the
fly and query statsitics and state)
SVN revision: 40536
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
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
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
currently does nothing and i have kept it VEEERY generic it's a pointer to a
native surface which can be just about anything - each engine will probably
define a format of its own you need to use VIA the native surface type.
2. add calls to set/get colorspace - moving this down into the engine level.
so far engines do nothing at all with it - but api is there.
3. clean up gl engine a bit - make it more standard.
SVN revision: 27389
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
far buffer, software_x11 and fb engines use it. need to make allother
software enignes use it next then the gl, cairo, xrender engines, then dfb.
it cuts out a LOT of duplicate code. makes writign a new engine or engine
variant much simpler
SVN revision: 20908
Cedric BAIL
Carsten Haitzler
Vincent Torri
sebastid