Sorry for not much time to reply to this in depth, probably raster will do it, by my point goes for the last statement:
On Wed, Apr 16, 2008 at 3:45 PM, Jose Gonzalez <[EMAIL PROTECTED]> wrote: > 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 > 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. > 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. The point of it being generic, at least for ME (not we, don't care about others agreeing or not) is to enable you to write such filters and plug them. You write then, you just have to implement the API and you're done. If you want to set a matrix, you specify it and you set it. If you want to be dependent on GL, do it on your code, use it from your application. Of course Evas should provide some good one, generic, by default. But I'll not work on this now (maybe in future). But so far what I want is to (_very rough_ draft of the possible API): - negotiate(to_filter_objects, parent filter, child filter) - bounding_boxes_get(to_filter_objects, ...) // maybe return a polygon, dunno - allocate(bbs) -> dst_surfs - apply(to_filter_objects, dst_surfs) On the first call we could try to be bit smarter and collapse filters we know about. Default negotiation is to allocate a temporary buffer to be used in apply(). The second call can be used to get the size of the required buffers to allocate, Evas will calculate the biggest BB if filters are negotiated do use the same buffer. This can be also used to mark evas region as dirty... maybe we can return a polygon here and support dirty areas as polygon in Evas... who knows. For now I'd just return a list/vector of rectangles to use, in the case we want disconnected regions (ie: exploding effects). The third major call is meant to allocate temporary buffers, which might be OpenGL framebuffers, simple malloc() regions.... The last major call would be apply() that would take care to draw things to its temporary buffer. The input, to_filter_objects, is the objects to use if they're not filtered by some non-cooperating filter before, or the result (tmp_buffer) with the result of previous filtering. As you can see it's all about negotiation. At least for me. That's not that complicated and would enable users to do nice effects. Of course we could provide nice filters by default, with great apis, but these can come later. We can do some tests with this and see if it will work as expected. As for API for these provided filters, we could use: Evas_Filter *f1 = evas_filter_rotation_new(evas, degree); Evas_Filter *f2 = evas_filter_blur_new(evas, EVAS_FILTER_BLUR_GAUSIAN, 2.5); Evas_Object *o = evas_object_image_add(evas); //... evas_object_filter_set(o, f1); evas_filter_filter_set(f1, f2); or you can make these special objects, like we have Smart Objects being Evas_Object... keep the API similar. Does it help a bit? Sorry not having much time to explain my ideas in a better way, or sounding too rude or writing some test code. -- Gustavo Sverzut Barbieri http://profusion.mobi Embedded Systems -------------------------------------- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (81) 9927 0010 ------------------------------------------------------------------------- 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
