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

Re: [E-devel] Evas & Evoak future changes

	Cedric writes:

> >	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.
> This would be really a must. As I am currently playing with some
> sdl engine, I see quite a lot of redundant code that could really
> benefit from some kind of surface allocator/destructor. Perhaps a
> first step would be to add this function to the current engine design.
> > 	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.
> This would be true on PC, but on embedded device you will really
> like the idea of using as much as possible the hardware.
> Preserving evas ability in this area is really something important
> in my opinion.

	Evas would do whatever the writer of the object type wants,
for that given engine target.. if you want to have the fuzzy object
implemented in the wombat engine this or that way, then that's what
you'd do.
	For things like 'path' based object types, even if the target
engine natively supports stroking and/or filling paths with textures
etc. one may still want to optionally cache the results of such to
engine-native buffers for redraws.. or not.. or even provide an option
to enable that.. The generic version can't assume anything about the
target engine, so it must draw things via software.. and wether or
not to cache rendered results or not.. Well, that depends on quite
a few things.

> > 	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
> > 'generic' one.
> This sound really good. Did you already start some work ? After
> playing a bit with evas engine, a lot of what you propose make sense
> and would really like to help in this area if I can.

	I have some and I'm missing some.. nor had I settled on the
exact set of buffer related engine funcs.. signatures/semantics, etc.
The object types themselves need some things, etc.

	I thought about getting back to this some time in the future,
but if you and maybe Jorge ar willing to give this a try, then it may
be better to go ahead and try and finish it off now -- it would be
very useful in many other ways as well, especially since much of the
image rendering pipeline needs to be redone in order to get image
fill rotation to happen.

	I tell you what, let me look things over a bit during the
weekend, and if you like you and maybe Jorge can do the same...
maybe discuss it with others on the list who have some experience
with evas/objects/engines.... and we can take it up again on Mon
or Tues, and maybe Carsten can add some thoughts.

	This is the kind of thing that would really benefit from
having an "experimental" CVS version of evas..  Understand though
that it would mean quite a bit of work to get it all done.. a lot
has to be re-written.