On Fri, Apr 11, 2008 at 4:29 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > Cedric wrote: > > > > On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez 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. > > > > > > The main difference is that of avoiding the iterative 'clipping' > mechanism as the single method for doing everything. > What you want is something like: A clips B clips C clips D clips > E clips F clips G clips H say, where H is eg. an image obj and G a > transform obj and F a rect obj and E a blur filter and D a gradient > obj and C a ..... with the result of obtaining a transformed image > which is multiplied by blurred rect which is multiplied by gradient > which is .... then composited to the dst. Also, some of these clippers > may be clipping other objs. > > Very succint, very extensive... very likely to be difficult to > optimize for simple, commom-use cases, and even more likely to not > be used in this kind of arbitrary generality. Also likely to be > problematic with smart objs and difficult to use for basic things.. > imagine setting a trnasform on an image obj that's already had a > rect set as a clip - one'd have to unset the rect clipper, set the > transf as the new clipper, and set the rect as the clipper of the > transform.. and that's just one example of the kinds of things that > come up with this approach. > > I'm suggesting that one avoid this temptation, leave clipping > as is for now (plain rects), and instead add separate api funcs to > set a geometric trnasform, to set a mask (image or grad, no masking > a mask), and to set certain kinds of 'effects' filters (blur, bumpmap, > ... possibly allow for chaining these).
Well, you misunderstood me then. Filters would behave like clippers, but not use the clipper mechs... I think I tried to say that in my email. We'd have both clippers and filters as separate lists. Clippers, in far, far, far.. future, will add some of what you want, as clip to a bitmap and get a mask, clip to a gradient and get nice fade-out of clipped items. That's what raster want to provide AFAIK. 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. Of course one could implement F1 as a weird filter that uses fragment shaders to provide a fade-out effect, so eliminating the need for that in clipper. > If one wants more than this, then there are several ways to > obtain things - eg. introduce a 'drawing obj' type which essentially > allows for one to iterate these things by allowing one to 'add' other > objs to it (much like a group obj), including ones like it, and > extend masks to also be of this type. > Anything beyond that should probably be the domain of custom > objs that can use whatever methods/apis they have access to.. gl, > shaders. whatever. > > But keep the core, built-in stuff simple, efficient, natural > and also flexible enough to obtain more complex things if desired. they will remain like this, no existing code should be influenced by these changes. -- 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
