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

[<jos...@ju...>]

	Ok, now that I have a bit more time to reply... :)

> i have a few doubts about objects and engines and how to implement
> what we need. I think the idea of making engines be just blitters
> is a good thing, also convert the objects to module units. But
> (as you noted) we have a problem when we want to implement an engine
> -specific render function for an object. so my question is "do we
> really need engine-specific render functions for objects types?"
> if the answer is "yes", then i think we have a problem:

	Oh yes, you do want engine-specific implementations of obj
rendering and other funcs.. That is, if you want to take advantage
of any features that that engine can provide -- and one such *very
important* feature might be faster rendering mechanisms (eg. hardware
accelerated paths).
	Having the engines be "just blitters", for all object types,
is not desirable.

> As i have said before, let developers build engines/objects/any
> module outside evas source is a *must*, that was one of the main
> goals of modules (also the load/unload for memory usage). So in
> this situation if you place the engine-specific render function
> on the object side you might need definitions (headers) that are
> part of the engine module, so the object must link/compile against
> those libs/headers (imho isnt a good option). If in the other side,
> you place the engine function on the engine side (sounds more logic)
> what you need is the object api / canvas api to know how to draw
> (as it is now).

	You could have people build their own engines outside the
evas src tree, and they could still use any of the object types that
evas would ship with... but they're just not going to get anything
but the generic software implementation of those types unless they
implement their own engine specific versions (which would be the
same as what you'd have if one didn't have engine specific obj-type
implementations at all and the engines were just-blitters).

	The canvas doesn't know how to draw anything. It just calls
object rendering functions - which just happen to be in the engines.
You must have knowledge of the engines internals, somehow, in order
to build implementations specific to it.. no way around it. It doesn't
matter where you put the funcs for rendering a given obj.
	But if you stick them in the engines, then every engine will
have to implement those functions, and only objects which are built-
in to the engines can get engine specific benefits - and there's more
than just rendering related to that.

> Now, if the second option is a good one, how do we override the
> object type functions in a common way, instead of the huge engine
> functions struct (becuase now it is too static if we plan to support
> "foreign" modules)?. solving this idea will let us implement also
> the object engine idea i coded. But first i would like to explain
> (again) the object engine :)

	That's what the 'generic' implementation would do :) It would
give an implementation, of any given object type, that would work
with *any* engine.

> As most of you already know, evoak was a canvas server based on
> ecore_[con, ipc] and evas. Ill explain the issues with the old and
> new evoaks (internally not the API).
> =

> Basically the problem with the first version of evoak was that it
> had an API over Evas (the same API, a wrapper over evas). So a
> modification in the evas api meant a modification on the evoak api,
> so the maintenance of evoak was hard because of the changes on Evas.
> =

> What does evoak need? it needs to save the state of objects locally,
> for the "get" functions, and send the commands to the server on a
> "set" function.  With this principles another approach instead of
> duplicating the evas code, was to let evas handle the state of
> objects (the canvas scene) as it does now and also on every "set"
> function, call an engine function (this is why it is called "object
> engine") which will send a protocol command. The problem with this
> is that now almost every "canvas api" function (object_resize,
> object_move, etc) have to have an engine callback, so the engine
> api will be even more bloated.
> =

	I've already commented a bit on this before, but let me expand
on it a bit :)
	If you want to serve the state of an "unknown" object, you're
going to have to be smart enough to query the object for it.. and
you're going to have to be smart enough to deal with transformations,
and possibly position dependent geometry variations, and other stuff.
	The canvas must query objs for a whole bunch of things as I've
mentioned before. Consider a true implementation of 'hit-detection'.
Evas doesn't really do a very refined version of this right now..
the only way to do it is to query the object-type for it. Same goes
for opaqueness, visibility, and a host of other things.
	Right now, it does a fairly simplified version of all this
for most objects.. and could do so, as desired, for any object type,
including not doing anything at all.

> This is a very simplistic resume of the approach ov evoak inside
> evas, i already explained a little more on the other evas thread,
> if someone has more questions i have no problem to answer them.
> =

> Now, how does it all matches with jose's ideas? is kind of hard to
> find a solution that allows simpler engines and also the possiblity
> to extend the canvas in a way evoak works.
> =

	Not at all :) The canvas will deal with the objects as they
provide themselves to it. The engines don't need to know anything
about that. They also can work with any object type, just not in the
most efficient way.

> Notice that evas already has some nice ideas that might be usefull
> for what we have discussing, this are the informers and the
> interceptors, basically an interceptor will be called before the
> object changes state, and an informer after (i.e evas events).

	You could do that.. but it's not going to give you, say,
hardware accelerated rendering, unless your engine supports that and
your obj can take advantage of it. :)


   jose.