On Thu, Apr 10, 2008 at 6:00 PM, Jose Gonzalez <[EMAIL PROTECTED]> 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. -- 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