On Thu, Apr 10, 2008 at 8:22 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > 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.
If _I_ would do it, I'd do it for usage with OpenGL or other hw-accelerated systems, so this would map easily to them and would be fast. 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 :-) -- 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
