Carsten Haitzler (The Rasterman) wrote:
> On Thu, 24 Apr 2008 14:54:20 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>
>   
>>       Ok, let me give you some 'criticisms' I have of parts of the
>> approaches to this filters stuff that both Carsten and Gustavo 
>> suggested, and let me start with:
>>
>>       I just don't see a realistic "need" for having a built-in
>> mechanism of arbitrary lists of arbitrary filters to be applied
>> to any evas obj (or the rendering of such an obj), or as a canvas
>> modifier object itself.
>>     
>
> why not? in the end if u make it simple like clip objects work, you 
> effectively
> build a list of filters as u apply one to another. example:
>
> to make a soft dropshadow for ANY objects you'd:
>
> 1. have a filter that makes a "copy" of an object's output/pixels
> 2. takes the copy stream and reduces color to just "Black"
> 3. offsets pixles by an amount
> 4. applies a blur filter to this.
>
>   

      Sure, and if you want to render an object with a multiplier color
and a blend op, at some point on the canvas, you could:

1. have a filter that makes a "copy" of an object's output/pixels
2. takes the copy stream and multiplies it by the given color
3. offsets pixles by an amount
etc...

      You can always break up any sufficiently involved operation into
some extended set of parts, and you can consider just about any kind of
operation as a 'filter'. This is not an argument for or against the
issue at hand. Are you suggesting that "move", "resize", "color", ... should
all be removed and made part of a general filter pipeline? Or conversely,
that the existence of such separate kinds of filters (move, resize,..)
is a good argument for the need for such a pipeline?

      What we're talking about is a realistic, real-time, need for an
arbitrary gfx filter pipeline that's automatic, ie. a sequence of gfx filters
is prepared and applied, if need be, when evas render calls.


> of course this is actually probably more sensical if a special "dropshadow
> anything" filter existed that just did all of this.
>
>   

      Errr.. Gee, how about that. Are you feeling ok, maybe too much partying 
lately..? :)


>>       I wish someone would point out an interesting, and/or common,
>> real-time gui use of something besides: one specialty filter (say a
>> blur or a bumpmap) followed by a geometric transform (and possibly
>> all clipped by a mask).
>>     
>
> as above.  :)
>   

      See what above... some artificial construct that you then point as
being basically just one standard filter (blur with radius,... params)?


>   
>>       Anything more involved than that I'd say should be left to
>> immediate-mode mechanisms for people to compose things as they
>> wish (working with image objs), ie. draw the obj to an image obj
>> and proceed to work with such.. use whatever eventual im obj to
>> represent whatever bizarre, complex, slowly-arrived-at result you
>> wanted.. I doubt one'd be going thru these steps all the time,
>> so might as well create what complex effect you want and save it
>> as an image obj for your actual real-time use (and any animations
>> on this kind of thing you'd probably want to do apart from that,
>> ie. on that result).
>>
>>     

____________________________________________________________
Summer Spa Sweepstakes
Enter for your chance to WIN a Summer Spa Vacation!
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UbeoRzA9UoKkFU8OyRY3e6l2cBkTpQR2y4vfE6h7LmpdPu/

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel

Reply via email to