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
* When fonts are added from files we will only load the details
* The first font is always loaded
* I know there is a patch for this on the list but this way seems better to me
SVN revision: 21964
debugging/fixing and likely int he end the exact same result of fixing them.
yes - we lose performance - but it actually is correct now :) if we want to
do such radical changes- i sugegst moving to premultiplied alpha and makign a
tonne of externally tested routines in a test harness first to compare
correctness and speed in an isolated environment.
SVN revision: 18947
do NOT depend on order operation precedence. it broke scaling. laos other
completely bizarre mmx things were going wrong with mm7 ending up not 0 so
i've had to force it to be 0.
SVN revision: 18811
--enable gl, qtopia and directfb enigines - they are either incomplete, buggy
or simply used so little that its not worth building unless the user REALLY
wants the support.
SVN revision: 18424
2. i reduced list note memory usage by 20% - shoudl work better with malloc
as ti is now a power of 2 as well
3. optimised evas internals to make use of event freezes to make e17'sw menu
popups a LOT snappier
4. fixed using last member of list nodes - bad - shoudl use api as this is
private stuff really
5. added config profile stuff to e17 u can literally maintain multiple
config profiles and choose which one at any time etc.
SVN revision: 15864
FONTSETS!
so u can do
Vera,Kochi,Blah ... etc.
as the font name
it will fall back font by font until it finds a char or finally fails.
this is for internationalisation support...
WHERD!
SVN revision: 13804
Carsten Haitzler
tilman
sebastid
Stafford Mitchell Horne