On Sat, Apr 12, 2008 at 4:53 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > I wrote: > > > Gustavo wrote: > > > > > >> Filters will just be filtered by filters, so it's like > >> "SO1(O1->F1)->F2->F3". Object O1 that is filtered by F1 and inside > >> Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 > >> will get these 3 filters. > >> Example, F1 could be blur, while F2 be rotation and F3 be scale. > >> > >> > >> > > BTW, this is not going to work well at all with things like > > projective transforms (eg. ones mimmicking 3D rotations) if you want > > to preserve perspective and such. Because you'd need to further > > translate the smart members by their position rel to the smart parent > > and other such complications. Your best bet here is to either let > > the members decide what to do with the parent transform, or to > > 'render' the untransformed smart-obj to a buffer and transform that. > > > > > Not that it's any less problematic with affine 2D ones in > general.. But again, unless you want to dictate the policy that > transformed smart objs should be rendered untransf to a buffer > and then that result transformed, you may want instead to have > smart-class functions for 'setting' a transform on a smart obj, > similar to what's now done with move, resize. > Also, if you want to split your transforms into 'commands' > rotate, translate, etc. then to get 3D kinds of transforms you'll > need to add axes to rotate around, or maybe aound a 3d vector (and > maybe a focal distance). > > 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 ;-) - 4x4 proj transf => good, one idea that we were considering. - 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 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. -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- 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
