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

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

On Friday 01 September 2006 08:02, jose_ogp@juno.com wrote:
> 	Jorge 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.

> 	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.