Gustavo wrote:

>>       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.
>
>   

      I don't think clippers should enable that - raster and others
may though. I already implemented this once.. and didn't like it.
I'd separate masking as its own operation, and leave clipping as is.

      As far as filters having their own api funcs but incorporating
both geometric transforms and various filter effects (blur, whatnot),
and chainable.. that may be ok (possibly still somewhat unwarranted
for most needs).


> 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.
>
>   

      That is very easy to obtain via (projective) transforms and
masks (image, grads, or general 'drawing objs'), without having to
invoke "fragment shaders".


>   
>>       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.
>   

       What does that have to do with anything we're discussing here?


-------------------------------------------------------------------------
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