[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas & Evoak future changes
> 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.
Well, the get/put functionality is actually a kind of "last
resort" thing. It's generally very slow to 'get' from a display
target.. but it would be there for very particular obj types that
need an argb copy of what's already been rendered in order for it
to 'do its thing'.. Most objs would not need this.
What they would use is some form of compositing to the
display target, or to a target specific buffer surface.
For this we'd have two sets of functions - one set that
'directly' composites a triple (argb buf, a8 buf, color) to a target
surface.. and one set that involves target specific buffers.
Many engines have some sort of native notion of a 'buffer'
that one can get/put data to, which they can composite to a target
surface.. eg. xrender has 'pictures', gl has at least 'textures',
etc.. and usually this compositing can be done with some 'transform'
(scaling, rotating, shearing,..) being specified.
Most of the hardware accelerated aspects that evas needs
really come from this compositing step. So what one can do is to
realize one's object to an (argb buf, a8 buf), and 'put' this (plus
maybe the global context color) on an engine provided buffer of some
sort. Then let the engine do the compositing of this to the target
surface. One can cache such buffers and only need re-generating/
putting the data from the obj when state changes require it.. and
thus obtain some good performance on that part - even though you
know nothing about what the object may be doing to realize itself
onto the argb/a8 buffers that it puts on engine provided buffers.
Some tests I've run show that even when the engine supports
functions for drawing things like sub-pixel positioned polygons,
it's actually faster to draw these in software and use the above.
When I say faster here, I mean not 10% or 30% faster.. I mean it's
like 20 or more times faster.
But the main reason for this re-design is really to allow
for both modular engines AND modular objects to work.. not just to
make it easier to add new engines supporting the current set (or
an extended set) of objects and/or their properties - though that
is certainly an added bonus.
Each object type is thus a collection of modules, one
for each engine it may want to provide an optimized implementation
for.. But it must provide at least one module - the 'generic' one.
The mechanism is then setup so that this generic module can work
with ANY engine - so long as the engine provides the required
buffer functions, and its general gfx context 'derives' from the
> 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.
> > ...
> > 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.
It would.. and it would make it easier to write any engine
without having to worry about giving specific implementations of
some set of objects at first.. Also, it would give loadable obj
types.. something which is very desirable (for various reasons).
Altough adding render-pre/post functions to smart objects would
also help in speeding self-rendering 'external' objects, having
the ability to put some of these as loadable obj-types would be
more efficient and faster - and allow for whatever engine specific
optimizations to be written as well.
However, I just don't see myself sending this imminently.
There's a lot still left to be finished off, and I have a large
amount of other stuff to do as well.. so I would say that it might
be better for you to go ahead with the object-engine work as you
I don't see any problem with keeping the 'object engine'
name you had.. but I guess you could also call it 'object server'?
As to where to insert it.... Ummmmm... I can't say offhand
> > Likely Carsten has his own views on this.
> well i hope raster joins this discussion, to know his ideas =)
Carsten is busy with so many things.. it would be nice
if he could help out here, but then again it would be nice if
I could help out more with e17 and other projects... I just don't
know anything about most and have only tiny-x amount of time to
do a load of work for evas as I believe would be useful.
Of course some may argue that evas doesn't need or want
things like: stroke and/or fill of lines/rects/polys/paths with
image/grad/color textures, or rotation/skewing of objs, or filters,
or general obj clipping, or loadable object types, or a cairo engine,
or canvas objects, or an object-server/engine, or any number of
things. That it's time to just stop fiddling with evas anymore,
leave it alone and concentrate on writing other aspects of the e
That's something people here who use evas, and maybe see
a possible future in its use over larger contexts, will have to
decide. I certainly don't feel 'compelled', or anything like that,
to do any more work on evas if that's the case.