[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[E-devel] Evas needs... ?

> >       I thought that Jorge (aka. turran) was going to do some
> > work on the evas fb engine, and also ecore_fb, but don't know if
> > he's had a chance to get to that or not.
> yeah i do have plans for it, but with the changes on the way evas
> engines will behave, i prefer to not touch it before those changes.
> btw a little offtopic, but now that the premul stuff is in, isnt a
> good time to continue thinking/start coding the next evas?

	It wouldn't hurt to fix those kinds of things now since
they are highly specific to the particular engine's internals.

	But, sure.. let's continue the discussion on re-vamping
evas' engine/objs internals. :)

	If you take a look at the engines, you'll see that as part
of the grads rewrite for the move to premul, I also did them so
that the engine funcs for grads now correspond exactly to the grad
api funcs plus the canvas level 'obj-funcs'.
	This is the general pattern needed in order to separate
'objs' from 'engines'.
	The next step is to do this for all the other current objs:
lines, rects, polys, text, and images (textblock and smart objs
are not dealt with at the engines level).
	This is straightforward for all but the image objs since
image related structures and funcs are used extensively and since
loaded images are basically shared resources.. But it can be done.

	Once all the objs have been thus redone, one can begin
to place the 'objs' into modular units (built-in and/or loadable)
which provide at least one generic implementation wich can hook
into any engine... plus they can also provide engine-specific
implementations for more refined/optimized versions for a given

	Ok, so what are the set of basic engine funcs, and obj
funcs, that will need to be provided?

	To be continued.... :)