Carsten wrote:
>> I also know that adding any of this to evas is going to
>> mean a fairly large re-working of the image internals (among
>> other things), and that although a general 'filters' mechanism
>> is a very powerful thing, there are many, many aspects here
>> that need to be considered carefully.
>>
>
> i know. i've been thinking of this for many years now. i've known what i need
> to do to make things like this work... rendering to intermediate buffers is
> what is needed. i actually didnt implement in the first evas because -
> pbuffers
> in gl were new and not widely supported at the time and fbo/render-to-texture
> didn't exist. so it got put in the "i can do it in software - but not with gl,
> ok - i'll skip for now" bucket.
>
>
True. This is something that's easy to forget. Well, this is
a perfect time for those who are fans of gl (plus good gfx drivers)
and want to see more support for gl in evas... to do something very
useful: Modify the current gl engine to use textures as render/update
(fbo) buffers.. and improve the gl engine in various other ways. :)
>> Now, despite the discussions that were done at bossa, it's
>> clear to me that not everyone there seems to have the same idea
>> as to just what was decided - if anything.
>>
>> First, it seemed that 'filters' were to be a new type of
>> evas object which were to be used via the current 'clipping'
>> api - at least that's what I thought was being proposed, and
>> you, raster, did as well.
>>
>
> it should be LIKE the clipping api
>
> filt = evas_object_filter_add();
> evas_object_resize(filt, 200, 200);
> evas_object_filter_effect_set(filt, EVAS_FILTER_CHILDREN_ONLY);
> evas_object_filter_type_set(filt, "blur/gaussian");
> evas_object_filter_parameter_int_set(filt, "radius", 10);
> evas_object_filter_add(filt, obj_to_blur);
> evas_object_show(filt);
> ...
>
> (for example - this is not fixed, but it is an IDEA).
>
Ok, that's certainly an interesting possibility.. except for
the 'children' part - Leave the children alone! Let the parent deal
with them.. ie. as is now done with other stuff: add a smart-class
function to 'add' (or whatever it ends up being) the filter to the
obj, and let the creators of the smart obj do whatever they want
with that..
Anyway... let's see what others think. :) Also, come up with
ways to add these kinds of things to edje/edc.
>> Gustavo then mentioned that no, it was to be thru a similar
>> mechanism, but not actually as clip objects.
>>
>
> gustavo is right. we COULD use clip api - but i think a clip-LIKE api is
> better
> for filters. keep clip stuff as-is.
>
>
One *could* of course... feel free to try and make it easy
to use, consistent, unambiguous, etc... :)
>> Finally, raster then further mentions something which seems
>> somewhat like some other vague stuff I'd mentioned as well, but
>> nothing seems particularly clear either.
>>
>> No mention is made of any real api for defining these 'filters'
>> or how to deal with a variety of things like image-fills/borders,
>> or with smart objects (apart from a vague remark about adjoining
>> parent filters to members), or how to best implement any of this
>> with the various engines (apart from some vague remarks about
>> gl shaders and a gallium3d lib), or how to represent these things
>> for use with things like edje, etc...
>>
>
> engines will need to be able to render to a buffer. they will need to be able
> to process that buffer with an algorithm. if the engine cannot do it itself,
> it
> can inherit from the software engine and the filter and all rendering to the
> buffer will be in software - thus the filter works, just more slowly. shaders
> in gl can accomplish this processing (when taking the buffer and rendering it
> to its parent - ie the canvas or another buffer).
>
Needs some work to various internals to make it easy to
'fall-back' to software for various things (not just filters).
-------------------------------------------------------------------------
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
