On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > I wrote: > >> However, as I said, I have no time to work on this ATM, so if you like > >> to try an alternative approach, please do it. Keep it as a branch > >> somewhere and share your results, someone may test it and see how well > >> it works, maybe it would suffice and this would be integrated, > >> everyone is happy :-) > > > > I've already tried both approaches, and others as well. There's > > nothing here that's new, though there's certainly more than one way > > to do anything. As to some 'branch' somewhere.. maybe it's best to > > wait and see how your approach works out and if that would suffice, > > integrate it as you say. > > :) > > I should add that I'm in the minority here - you, vincent, and > raster (maybe many others) all think that the generic 'clipping' pipeline > is the best way to go. > I'd just like to see one implementation of this that works well with all > engines, maps naturally (in its full generality) to real-time evas obj > rendering, is easy for people to use, and has no > surprises/difficulties/semantic-issues/etc.
I must say that I don't really see the difference between your two proposal. Perhaps if you can propose the set of functions that will be exported by Evas to the external developper, it will be easier to understand and discuss. -- Cedric BAIL ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
