I wrote:
> Carsten wrote:
>
>> On Sat, 26 Apr 2008 00:42:47 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
>>
>>
>>> Gustavo wrote:
>>>
>>>
>>>> On Thu, Apr 24, 2008 at 3:54 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote:
>>>>
>>>>
>>>>
>>>>> 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.
>>>>>
>>>>> 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).
>>>>>
>>>>>
>>>>>
>>>> in order to do cover flow-like we need:
>>>> 1 - projection;
>>>> 2 - mirror;
>>>> 3 - blur the mirror;
>>>>
>>>>
>>>>
>>> That's one way, though in fact projection and mirror are
>>> expressible as one transform. The simplest way to do this is to
>>> perform the required transform and mask with a suitable gardient-
>>> like image (could also be defined as a single especialty filter).
>>> Would you like me to send you some simple software-based
>>> examples of how you can do this?
>>>
>>>
>> yes projection and mirror can be merged, but blur is still a separate
>> filter...
>> so point still stands that u need to have filter pipelines. the ability to
>> know
>> what parts of the screen have what filter chain applied to what source object
>> data
>>
>>
>>
>
> No you don't *need* to, not for this case - not if you have separate
> transforms/masks and a 'filter set' mechanism. It would reduce to what I
> stated: One specialty filter followed by a transform (with an optional mask
> which itself can be filtered, transformed - not masked). Though mind you,
> going thru a blur just to get a reflection-like effect is really overkill,
> just do a reflection with a 'fade' alpha mask.. you have some demos man.
>
> If you really must have a serial pipeline of filters, then just do
> the "filter a filter" bit and you can have that.. feel free to implement away,
> unless Gustavo beats you to it. I'll hold off on the transforms and masks.
>
>
Let me just make it clear what I'm saying here:
I think a general (or just serial) gfx filter pipeline for evas render
is largely unnecessary and mostly useless for real-time gui stuff.. I'd say
just leave complex pipelines to immediate-mode mechanisms. But it you really
want such a thing, say via the 'filter a filter' method, then fine -- it'll
complicate the general implementation, maybe make it harder to optimize some
things, maybe create some issues with hit-detection... but it can be done.
However, what I think would be an absolutely terrible idea is to have
"transforms" and "masks" exclusively given via such a filters approach, rather
than via their own api. I'll never be convinced of that anymore than I'll be
convinced that "move", "resize", "color", ... should also be given solely via
a filters api rather than via their own.
____________________________________________________________
Get the sign you need for the impact you want. Click now!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oB4gst0qxcL1qUrHBgqD0e5pqKJTiYgtANDCwkESnjnLVes/
-------------------------------------------------------------------------
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
