[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas & Evoak future changes
On 8/30/06, firstname.lastname@example.org <email@example.com> wrote:
> > So, the gfx parts of the engines (and some that are not
> > directly gfx aspects) are really mostly a bunch of functions that
> > apply to each object type, and some core functions that apply to
> > all object types, and some that apply to display-target aspects.
> > So, the 'engines' are in large part just the obj types themselves.
> > Extending the engines is thus largely equivalent to extending
> > the set of object types, and possibly the global gfx context.
> > If one can suitably set that up, then there's no need to
> > export a lot of specific internals to get modularization.
> im not sure i actually understand what you are trying to explain :)
> maybe you mean that if i setup correctly an API for "object engines"
> there's no need to export internal functions? you are correct, and
> then is my fault to no explain myself correctly =)
> on the mail i sent there two different things:
> - make an object engine
> - export internal functions
> (note that the last isnt needed for the first)
> i'll explain a little more on what i did with my local version:
> in current evas each engine should declare a Evas_Func and fill the
> functions (this is the engine API). so the idea is to make another
> type of engine with its own type of functions struct, like
> Evas_Engine_Object_Func and make current struct like
> Evas_Engine_Render_Func. note that the comparision if the engine is
> of type render or object is done at the evas_engine subsystem i
> explained on the previous email. the type of functions an "object
> engine" should declare in its struct are for example a function for
> an object_move, object_resize, etc. there's no point that a normal
> engine (render) must define those functions too. so if i understood
> correctly this is the engine API which i already implemented in my
> local version.
I see.. a bit.. :) I think it would be great for evas to have
the 'object engine' aspect you developed.. though it's just never
truly clear what object related functions are needed on a per object
type basis. If you can have it without exporting the 'engine funcs'
then that would be best I think (however, if this 'object engine'
relates to exporting functions related to the canvas level "object
functions" then see below).
Exporting anything to do with the 'render engine' (the current
engine funcs) would be premature, and in fact, I personally would like
to get rid of most of the engine funcs - replaced by 'obj types'.
Let me give you a better idea of what I have in mind here
in case you find it of interest or relevant somehow.. it does seem
like there's some overlap between what you describe as an obj-engine
and some things I believe the render part of the engines could be
Currently, if you wanted to add a new type of object to evas,
then at the canvas level you need to add the set of api functions and
the set of internal obj-funcs. At the engines level, you might have to
add some set of engine functions for dealing with the states available
through the obj's api, and possibly a render function.
One way to achieve all this in a simple manner is to add
engine functions which not only mirror the obj's api funcs, but also
funcs which mirror the obj-funcs which all canvas objs may/need define
ie. things like new, free, render, render-pre, is-visible,...
If we do this for all objs, then the engine funcs relating
to particular obj types can instead be considered as funcs belonging
to an 'obj-type' structure associated with that type of obj. The set
of such obj-types would thus become what is now the engine funcs..
They would no longer be held by an evas instance, but rather by an
instance of the object-type relative to the given evas instance.
Some of the funcs can be display-target specific (for more
efficient implementations) - but there's a way to actually have a
generic, or virtual, argb target (similar to the buffer engine) from
which one could obtain any other targets.. IF the display targets
support certain 'standard' functionality, namely:
1. the ability to 'grab' a selected part of the target surafce to an
argb buffer, and to 'put' an argb buffer onto the target surface.
2. the ability to composite an argb buffer and an a8 mask onto the
These two things, and some similar others, are what I would
have as part of the engine funcs.. instead of the obj specific stuff.
With just those two - you can go far.. albeit not necessarily
the most efficient means of "realizing" an object type in a given
display target, but a general fallback mechanism at least (that can
be optimized per engine as desired later) - and one which would allow
you to do things like add brand new display targets that work with
object types it knows nothing about.
If one sets things up as 'object types', rather than 'engine
funcs', plus some 'standard' funcs related to argb buffers... then
not much is needed to be shared beyond this.. image and font loading/
caching, and similar such.
However, for loadable obj types one would need to export at
least its external api, and optionally the internal 'object functions'
part that each obj type must have internally.. it also requires that
the types be able to uniquely identify themselves, wether via a full-
name and/or id...
Anyway, that's what I believe is needed to get extensible
object types and display-targets working together..
But the parts I mentioned about replacing the current engine
func signatures (to something similar to obj api funcs and obj-funcs)
is needed in order to obtain desired functionality in a coherent way,
wether or not they get moved to 'object types' or whatnot..
ok! now i understand what you mean on the first place, i totally agree with you.
in the current evas in order to make a new engine you have to define
all the current engine functions or at least inherit the software
engine (almost all engines do that), this is pointless because the
objects (besides the line and rectangle) are not common in all
engines, another example: almost all engines (ie. X, dfb, sdl, cairo,
whatever) do support images but not the current image object api
(border_set, ...) . so as you said if you plan to add stroke to the
line object it will be even more difficult to find a backend that
supports what evas needs, so you still depend on the software engine
to do the work. maybe the solution is to have just the functionality
you said on the engine side: blit/copy from/to target surface, it may
look very similar to what cairo defines as a backend.
just one last thing, with this changes in mind, in what level would
you insert the "object engine" (i guess it wont be called like that
anymore) the idea of making a layer above the object functions (API
object functions, _move, _resize, _image_file_set, rectangle_add, etc)
was to avoid duplicating functions on evoak. evas still maintains the
state of objects but after a state change the "object engine" (evoak
engine) sends a protocol's command to the evoak server. the main idea
is to set up callbacks for any object state change.
> about the internal headers thing, is to actually have the possibility
> to use evas internal functions on modules out of the main source
> tree, not only engines, but loaders, savers, even objects.
> dont know if this is clearer or it isnt even the answer you were
> expecting =)
The obj-engine sounds nice.. :) I just think that exporting
many of these things may just be too pre-mature - regardless of how
the objs and engines and such eventually end up looking.
i agree, so a good previous design will be usefull. nice you answered
the mail =)
Likely Carsten has his own views on this.
well i hope raster joins this discussion, to know his ideas =)
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
enlightenment-devel mailing list