[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas needs... ?
On 10/9/06, firstname.lastname@example.org <email@example.com> wrote:
> To be continued.... :)
Well, the prior emails pretty much outline all that I have in
mind here as far as objs/engines re-structuring: Modular units which
when called upon to add an evas obj to an evas canvas would either
use a default 'generic' set of funcs, or load an implementation that
is specific to the engine associated with that evas.. plus a set of
argb32/a8 and other buffer related set of functions that all engines
would provide in order to facilitate generic and other rendering.
I should add that this is just a minor modification of the
current evas design - just allowing for modular/loadable obj-types
along with loadable engines. It will still have the same layers/objs
model, same updates and events mechanisms, etc... all of which,
I should also add, was designed and written by Carsten.
Jorge's "object server" idea is the only real new thing --
I'll have to let him explain that himself as I know nothing about it.
There is much that one can consider about "canvases", and
there seems to have been a lot of activity recently by Qt on this,
along with their own version of edje-theming using svg and css docs.
Any thoughts, comments, suggestions, ... ?
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:
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).
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"
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 :)
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
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.
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).
* btw, as i said on irc the evoak and the evas modified versions are
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
enlightenment-devel mailing list