Gustavo wrote:
>> PS.
>> I'd just set a 4x4 proj transf (you can get some funky curved
>> stuff that way) and have utility functions for generating such in
>> various ways (eg. for obtaining one from four dst points, for
>> composing two transforms, etc.).
>>
>
> Ok, trying to reply to the torrent of ideas from you ;-)
>
No torrent of ideas, just simple basic things that I've already
run across and thought might help for you to keep in mind.
> - 4x4 proj transf => good, one idea that we were considering.
>
That's very nice for "we". :)
> - filter chaining: needs evaluation on good api to negotiate
> between filters, those that can be done within the matrix (ie: just
> add to transf matrix), do, others will require the intermediate buffer
> and will operate on it. So Rotate+Translate+Blur would generate
> Rotate+Translate in matrix, output a temporary buffer that blur would
> operate on. This may be suboptimal, but is very easy to work on.
> - rely on hw-acceleration (shaders and like): it's easy, it's
> almost everywhere and people are gaining market share by naively using
> it. We don't even allow users to use it. If you have or not such great
> hardware, you're unable to use it today. So why not expose this and
> let users use their hardware? Also, we can still support some of
> these in software (ie: matrix transf) easily, while others we can
> simple ignore. Most users (ie: E17) will try to keep with
> supported-everywhere, avoiding things that might depend on hardware.
> But others (ie: Rage) could try to use these fancy effects, since they
> know most of their users will have such hardware. Also, we could use
>
Sure, and that's why things like 'native surfaces' or other
methods for custom rendering would be useful - so that people can
do those kinds of things if they wish.
> Gallium3D or even go with LLVM directly to get some kind of JIT and
> have software-only implementation that is highly optimized, without
> having to care much about it ourselves.
>
> All in all, this "filter" thing is all about exposing some of hardware
> acceleration without having to explicitly implement it in Evas (as
> it's done now for things like YUV-RGB conversion, Scale, Colorize,
> Fade, ...). Actually I was about to go with this individual
> implementation, like adding evas_object_rotate() and like, but raster
> and others convinced me that going with a generic filter
> implementation would be more extensible. Going with super-fast custom
> case for each of this will span a huge number of function
> implementations (ie: rotate solid->solid, rotate transp->solid, rotate
> transp+alpha->solid, ... all of these for C, MMX, SSE, SSE2, Altivec,
> 16bpp, ...), since this is non-sense for such things that are barely
> used, let's make it more generic and have the optimizations to be done
> elsewhere.
>
Well, that sounds great! Looking forward to seeing this finally
in evas. :)
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
