On Sun, Apr 13, 2008 at 3:58 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > 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.
that was a joke because you replied about 3 times to yourself, adding more ideas :-) > > - 4x4 proj transf => good, one idea that we were considering. > > > > That's very nice for "we". :) you mean because of me? Or because of others? At least raster, if you ask him, he have tons of ideas on how to do things, he have considered almost every case I wondered and the problems come from here: he wants to implement the final super-uber solution to fix them all and he never have time to do it. The only thing that I added to most things were simpler solution to fix part of the problem and improve this later :-P > > - 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. AFAIU, the idea is already there, just need finishing? (About that other mail) > > 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. :) don't be too excited... it will take time to have someone to do that. Also, we finally have a release plan, no fixed dates yet, but the order is already there: EET, Embryo, Evas, Edje and then E (probably entrance will go earlier?)... so Evas is very close in the list and might get frozen soon, this would have to go in a branch and wait for the next coding window to get in. -- 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
