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

Re: [E-devel] Evas needs... ?



>	Ok, so what are the set of basic engine funcs, and obj
> funcs, that will need to be provided?
> 
>	To be continued.... :)
>

	Well, let's take a look at 'objs' first. Internally, the
basic evas_obj structure keeps some things that we're interested
in here:
	Its 'type' name and 'magic' number, some state relating
to the general graphics context (color, clip obj, ...), a pointer
to the 'data' that is associated with the instance of that type
of obj, and a pointer 'func' to the set of obj_funcs that all evas
objs need to provide at the canvas level.
	These obj_funcs include things like the render, render-pre/
post funcs, a destroy func, and a few others.. Not all are tied to
engine funcs, and not all need be used at the canvas level in order
to implement an evas obj.
	The 'data' pointer holds things specific to each obj type,
such as canvas level graphics state that is particular to that type
plus usually some data pointer that exixts at the engines level,
plus whatever other stuff the canvas level implementation of the
obj might need.

	What we want to do is to replace the above set of things
with a pointer to a structure that holds all this but extends the
set of obj_funcs suitably.. and have that set of funcs be provided
by a module as its funcs. That'll be our object_type -- basically
all that exists in each canvas file "evas_object_[blah].c" will be
suitably transformed into an 'object_type'.
	We don't need to get too sophisticated here to start with,
just re-use the current module structure and such.

	I will give you more deatils on the particulars of the
data structures later, but this gives the general idea.

	This is something that raster had actually wanted to do
sometime back.. but later became less supportive of it since he
got the idea that I was bent on destroying smart-objs :)
	It's true that they have some issues, but they are also
extremely useful, so NO I no longer feel that they must die.
One can do a bit more with them internally and such, but they
don't need to go.

	Now we come to the crucial point - How do we connect the
obj_type funcs, and in particular the render and graphics state
related funcs, with an engine that one may know nothing about?
	Clearly, for a 'generic' implementation, we need a
'standard' base from which all others can be converted to/fro -
and that is an argb32/a8 based implementation.

	Consider what people do when they want to draw something
or other that suits their particular needs: They create an evas
image object, generate argb32 data with the pixels they want,
and set the data to the image obj -- evas takes care of the rest.
	This has two major limitations - it can be inefficient
in that one doesn't know when to draw or not per state changes,
and there's no way to provide a more engine specific version
even if one could do so.

	The first one can be greatly helped by allowing one to
provide render-pre/post functions (for image objs in this case),
and possibly also by providing a 'render' callback (which would
pass a region that needs updating). The render-callback approach
can actually be a bit slower than the pre/post one since an object
may be rendered several times, over different regions, in a single
evas-render call, and is really best only for very dynamically
varying objs (ie. state is changing on every evas render call).

	So, we need to at least put these pre/post calls into
evas objs.. in particular image and smart objs.

	But it's only half a solution.. we really need to push
objs out of the engines as described above -- let the engines
provide basic functionality of several kinds, and let the objs
give their own implementations, a generic one, plus any engine
specific ones as their writers see fit.

	To be continued... :)

   jose.