Gustavo wrote:
> I agree with use case of fixed filters, actually the proposed
> filters cover more than what I expect. What I disagree is
> _having_ to implement a span of combinations in order to optimize
> it for all engines, it will not worth the pain. Ok if one wants
> to do that, but if we say such feature would just be accepted
> if this is done we'll never have it.
> If you like feel free to rephrase it on wiki.
I actually agree with Gustavo here somewhat, and that's
why I'm not sure if exposing a generic filters pipeline is the
'best' way to achieve things like transforms, reflections, blur,
bumpmap...
It's the requirement of chaining arbitrary numbers of these
that creates difficulty, inefficiency, and is often just not that
useful for most real-time gui use cases.
Make it easy to do some very usefull, interesting things
very well, and possible for people to do their own custom things --
hwd accel or not, shading language or not.
Also, consider just how you're going to deal with things like
image borders, with image fills, with compound objects, with 'custom'
objects, with events, etc. And how you're going to expose any of
these things in something like edje or whatever similar, deal with
layouts, alignment, etc.
_____________________________________________________________
Live your dreams. Click here to find information on becoming a lawyer.
http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3oFGmtTsWdLM7EXhh9ojhGZopcus7flUVAOgaC2By5aithnK/
-------------------------------------------------------------------------
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
