Gustavo wrote: > On Thu, Apr 10, 2008 at 6:00 PM, Jose Gonzalez wrote: > >> Just wondering if any progress has been made on this (eg. >> Gustavo, Vincent, ...?), or if anyone from the SoC is planning to >> give it a try? >> > > I haven't touch my development environment for a while now. This > company startup is killing all of my time, and what's left is dealing > with clients and their needs :-/ Things should be back to normal in > some weeks, then I plan to work at this, maybe it will be a client > request, who knows! ;-) > > > >> If not, then maybe I'll spend a bit of time to at least get the >> ball rolling on this for evas.. at least get image fill-transforms >> (affine ones), and see about the rest later. >> I personally won't do a generic clipping mechanism to include >> obj transforms/filters/masks/... I just don't think that kind of >> approach is worth it in evas (I did much of this before and didn't >> like it then), and would personally break things up into separate >> transforms, masks (image objs only), and filters (and keep clipping >> as it pretty much is right now). >> > > Well, what we've discussed at BossaConference, raster, cedric and > others might complement/correct me here: add a mechanism similar to > clip as it would accumulate various filters (so rotation + shear + ... > will look fine). Make a function available for the filter to query for > the output window (given these objects, what's the output bounding > box), then allocate a semi-transparent buffer and blit them all there, > apply the filter to this buffer when going to the end destination > (output buffer). This have couple of "issues", like you cannot have > filtered and non-filtered interleaved, but I think this is acceptable > given the easy it will bring to implementation and it should cover > most of the cases. Someone need to think about how to apply it to > smart objects, if we can do a automatic apply-to-all-member or provide > a specific smart api for it... for clippers, usually the smart object > creates an internal clipper and all members that should be clipped > will be clipped to it (it's in Edje, for example). But if we create a > "dummy" filter for the smart, then we might have lots of overhead if > the implementation is naive :-/ > Summary: > - similar to clip; > - filters provide a way to get the output window (bounding box) > given a set of 'filtered' objects; > - filters allocate a temporary ARGB buffer, all objects are > rendered there in order, then this buffer is filtered and the output > is placed at the screen (outbuf). Maybe the implementation will be > smart enough and filters should also return if the image should be > ARGB or RGB (ie: rotate a jpeg) and if the output have holes and > should be handled as transparent or not (rotate a jpeg = transparent > area, blur a jpeg = opaque area). These buffers can be GL Framebuffer > Objects... > - filters should work based on the output window, this will > avoid "holes" in the output for some filters (ie: rotation). Maybe it > can be flexible enough to support the other way? Does it worth to have > both? > - not clear on how to go with smart objects api, needs evaluation. > >
This is exactly what I don't like.. It's complex, slow, and I feel not really needed or warranted. Most of what people really want is fairly simple - transform an object and possibly mask it with an image or gadient (itself possibly transformed), possibly with some 'effects' filter applied (pointwise or spatial), and composite with the dst surface (image objs can also have a separate fill-transfom set on them much like grad objs now allow for fill rotations). This can be done easily and efficiently via separate transforms, masks, and a certain set of 'effects' filters (blur, cmods, etc), if need be.. and avoid complexities of modifiers of modifiers of modifiers of .... with no clear mechanism for optimization except happy buffer land. But if everyone feels that the generalized 'clip' mechanism is the way to go.. then fine, please do carry on. ------------------------------------------------------------------------- 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