Vincent wrote:
> > I think that we should add evas filters. It should be very
> > interresting for student (study of the internal behaviour of evas,
> > interresting algorithm to perfmorm different filters...).
> > Rotation, perspective, reflection can be a good beginning and
> > maybe add gradient clips, blur ....
Indeed, those things would be interesting objects of study
for those leaning to gfx stuff.
In practice, we already have fast software implementations
of all those things, and there are plenty of gl based methods out
there for these as well (though a generic shading-language like
approach could be very good here, regardless of the backend).
> actually, there is already a mention about evas filters in the wiki.
> But maybe we should be a bit more precise on which filters we would
> like
>
> That makes me think that we must add turran's work
Absolutely. But there are certain obstacles to be overcome.
Jorge's work on enesim and other of his efl-research work
are still in flux and early development.. he needs help with those.
Anyone interested in gfx and wanting to give a hand should contact
him about things.
But assuming all that is done.. there are even bigger issues
to deal with regarding evas itself.
First of all, there's the question of just HOW to 'add' such
capabilities (filters, transforms, whatnot) to evas... not how to
implement the underlying gfx algos, we know how to do that.. but how
to expose these capabilities thru the api in a way that makes sense
for evas and edje say.
If you want an analogy here, think of html and assume you've
got this nifty idea of adding filters/transforms to image tags, maybe
just via css styling, or that you want to add vgfx elements.. How are
you going to make this work? Well, that's kind of the problem here
with evas and edje.
Secondly, again assuming you've now got that worked out, you
then have facing you the realities of evas' current internals to
work with.. and there you have some real headaches to deal with.
In particular, the way that image stuff is dealt with internally,
and the way the engines are used by the api.
These things mean a fairly large re-write of evas internals,
stuff has been shoved-in again and again without taking the time
to redo internals when it would've been easier to do so. Now, it's
a large, messy bit of work that needs redoing.. work that's not easy
to follow for anyone but the persons who wrote the initial code --
It's always much easier to understand one's own convoluted mess than
someone else's clear organized stuff.. and much, much more difficult
to follow someone else's not-so-clear stuff.
Wether it gets done or not, there's a lesson here for people
to keep in mind as they develop stuff in e-land.
_____________________________________________________________
Make up to $100/hour by getting a degree in Web Design. Click Now!
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oHUEnY1AXtj4nEATvMInnIAsEfechiubYcUh7COaDvsWRzq/
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
enlightenment-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
