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

Reply via email to