On Wed, 16 Apr 2008 14:45:49 -0400 Jose Gonzalez <[EMAIL PROTECTED]> babbled:
> Carsten wrote: > > >> Anyway... Since you're still thinking about all this, and > >> since this has already been discussed at bossa, I'll drop the issue. > >> > > > > there is always room for input and discussion. until someone actually > > knuckles down and starts doing this, discussion is good as it means we will > > explore all the use cases, corner cases, issues etc. you did bring up the > > good point of > > Ok, I'll give you some further 'input' on all this. :) > > Part of the problem here is that something as large and > important to evas as this needs further public discussion... > and mentioning decisions/discussions by an unspecified 'we', > or possible feature requests by 'clients', is not a good way to > get this done. > > 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. > 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). > 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. > 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). > In short, it's all been mostly a lot of vague nothing. > > So, does anyone have anything more concrete to propose here? > Perhaps some further specifics discussed at bossa? If not, then I > will suggest some. see above > jose. > > > PS. > Some here would like to have ultimately flexible 'filters' > defined via some cpu&gpu supported "shading language" (a kind of > gfx scripting mechanism), but I seriously doubt that anyone here > is going to spend the time and effort required to design and > implement such a thing for evas. Thus, if evas' filters/transforms agred. i think we need a set of fixed COMMON filter we can EXTEND (ie like engines and loaders - they are modules). and engine may implement the filter directly, not at al (thus fall back to software provided by the filter module). > system is designed exclusively around such an approach, it would > mean a hard dependence on eith gl-shaders or gallium3d or some > such lib that would offer this functionality. yes. i think that would be BAD. we really need probably at most 5-10 common filters (blur, recoloroings, transforms, other distortions...) > I believe this should be an option.. ie. an optionally > compiled, loadable ability, not a built-in requirement for evas > just to allow for geometric transforms, especially since these > are so easily obtained with software and readily supported in > xrender and gl. yup. agreed. -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
