it sould be
2. fixed edje handling of delete of objects so we don't lose clip info if we
move a swallowed object out
3. fix up norender stuff for evas a bit
4. pants.
5. coogee beach (sydney) in summer right now is beatiful - KICK ASS!
SVN revision: 28102
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
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
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
2. be able to skip a copy in certain cases when scaling - should improve
speed in several situations - evas is defintiely not optimal :)
SVN revision: 19983
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
parent smart object IF there is a callback set. ie. if there is a key down
callback set and propagae is set to false then the key event will not
prpagate to the parent as long as the child gets the key down events and has
the callback set.
SVN revision: 18123
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
datatypes... i have by default changed the coord datatypes to be ints instead
of doubles... not - READ your headers carefully - they are Evas_Coord types.
dont ASSUME them to be anything except a scalar of some sort your compiler
can handle and cast. (coudl be int, long, long long, short, double, float etc.)
SVN revision: 9924
1. evas line draws of 2 pixelin size work now. oops!
2. font faces are shared between multiple sizes without a performance hit! yay!
SVN revision: 8660
api to set a font "source" (blank is normal filing system) but the source can
be a device or file etc. in this case it currently supports eet files as the
source and then the font name is used as a key in th eet file as to where to
find the font - edb support would be trivial to add. :) if the font is not
found in the "source" it falls back to the font path etc.
SVN revision: 8625
allows me to be able to virtualize he canvas co-ordinate system. right now
it's doubles. i can now move to floats, int's etc. with a recompile (and well
recompile all depending apps too). it's still ACTUALLY doubles, just all
typedef'ed now. i've also changed booleans to actual boolean types (not an
int), all code will keep working - but i'd highly suggest moving your code to
use these types if interacting with evas.
SVN revision: 7644
with texture upload. it does NOt check error returns anywhere from gl... this
may mean issues with LOTs of images, LARGE images etc. need to fix that later
SVN revision: 7432
speed of texture uploads. anyone want to help? i've tried many things... and
nothing semms to work. this is a major bottlneck for evas gl engine
performance (apart from text - which is simply a matter of finishing off
properly)
SVN revision: 7428
a dozen key grabs at any time may impact key event handling a little...
oh yeah.. added to the api .. now theres a modifier mask and a not_mask. the
not mas means "grab the key only if NONE of these modifiers are active and
only if one or more of the mask modifiers are active). using this you can
easily select allmodifiers, none, or a certain set of modifiers. if you need
more than that put in multiple grabs then :) to just have that exact set of
modifiers grabbed have not_mask be the inverse of mask. :)
SVN revision: 6546
are done now too - when an interceptor is set it takes over from the actual
call it intercepts and now that call is responsible for doing the
move/resize/raise/lower etc. (method overriding)
SVN revision: 6490
has been show, hidden, moved, resized or restacked :) handy for making
widgets (ie child widget got resized.. parent can adjust to fit child widget).
also interceptors.. designed to allow callbacks to intercept move, resize,
show, hide and restacking calls and modiy behavior (handy for widget sets
too!)
SVN revision: 6488