Re: [E-devel] Evas transforms/filters/etc.
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
Re: [E-devel] Evas transforms/filters/etc.
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
Re: [E-devel] Evas transforms/filters/etc.
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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] Evas transforms/filters/etc.
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. of course this is actually probably more sensical if a special dropshadow anything filter existed that just did all of this. 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. :) 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). - 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 -- - Codito, ergo sum - I code, therefore I am -- The Rasterman (Carsten Haitzler)[EMAIL PROTECTED] - 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
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: One other aspect that needs to be addressed has to do with the very notion Gustavo mentioned about negotiating buffer sizes that a filter/transform might need for putting results to.. and in fact this also covers things like calculating update rects when dealing with these things at the canvas level. The problem is that it may be difficult, in general, to obtain 'bounds' for these kinds of operations on objects. that's true for other parts as well, and I like raster's simplification to let's keep it to rectangles. Of course we could have any shape as clip or dirty area, but it doesn't pay off. All in all, let's keep areas as a set of rectangles. They're easier to operate and provide a good approximation for the first implementation. As you said, if calculate the proper coordinates are that difficult, then just request for whole-screen buffers and brute force :-P It can be 'difficult' in certain ways, eg. inefficient to compute or un-intuitive results (translation before or after), etc. For affine/proj coordinate transforms one can always compute the target bounds of whatever input rect to transform (the fact is that one doesn't really transform objects, but rather coordinate systems), but some transforms make it easier to do that than others (eg. it's very easy and natural for for affine ones). And remember, these regions need to be known every time the object might need redrawing.. and it'd be good to keep update areas small if one can make use of that. :) For arbitrary filters it'll just have to be the case that the filter will need to provide a function giving such data.. though actually it's not completely clear if a surface 'filter' should require a target buffer different in size from the input surface size for its action. It very much depends on what semantics one really wants from the concept of 'surface filters'. But even if one restricts oneself to minimal bounding rects, for updates and such, there's also the issue of 'picking' to be dealt with. When it comes to that, ie. determining if a canvas point is 'inside' the (filtered/transformed) object, there are aspects that need to be decided if one wants to chain arbitrary such filters. One will at least need the filter to provide such a 'picking' function (the point to be tested against being in target space), but that won't be enough if filters are chained - one will also need the filters to provide a function to transform a given target point into a src one, or one'll have to assume the identity function by default. I imagine this kind of thing isn't done much, that most uses of surface-filters (ie. image filters) are as a means to affect image pixels only for the sake of obtaining the desired resulting effect, even if they do use coordinate transformations as well as sampling and pixel/color modifications... ie. such 'filters' are mostly interpreted as image pixel manipulation methods, not as part of a more detailed user-interface mechanism that needs explicit support for user/model coordinates. This is, in part, one reason why I think it's best to keep affine/proj coordinate transforms separate from a 'filters' notion, - 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
Re: [E-devel] Evas transforms/filters/etc.
Getting back to the evas filters/transforms stuff... One other aspect that needs to be addressed has to do with the very notion Gustavo mentioned about negotiating buffer sizes that a filter/transform might need for putting results to.. and in fact this also covers things like calculating update rects when dealing with these things at the canvas level. The problem is that it may be difficult, in general, to obtain 'bounds' for these kinds of operations on objects. Let's take the simple case of transformations. Though it's easy to deal with this for affine ones, projective ones are a bit more of a pain. There are ways to deal with this, eg. by restricting the way the transforms are obtained (say to those that are equivalent to texture-mapping a given quad), or other things, but in general it's something that poses difficulty or inefficiency. In general, the complexity and inefficiency of determining bounds or update regions increases rapidly as one allows complex filters/transforms and arbitrary chaining of these, and an object's 'geometry' no longer determines its actual drawn geometry or bounds on the canvas in a simple way. Many who use gl for rendering often don't bother with update rects, and simply re-draw the whole scene when updates are needed, or require one to manually provide the update rects. Related to this is the issue of 'picking', ie. determining whether a given canvas point lies 'over' the drawn object. This is fairly easy to deal with for transforms, affine or projective, but may also pose issues with general filters (consider one that turns an image into a blurry pretzel shape, or breaks it up into many scattered pieces all over ...). One could require that the filter provide a function to do the 'picking', but this would have to be in an inverse way, ie. from target space to source space.. and most likely would end up being a simple bounds check, which is generally very coarse. The issues here are not trivial - arbitrary filters/tranfs are difficult to deal with for ui aspects. They're fine for gfx presentations kinds of things, but not so naturally dealt with for user interfacing. These kinds of things at one point led me to consider one possibility of NOT having filters/tranfs on arbitrary objects, but rather only on objects 'bound' to a 2d-scene kind of obj. This was a fairly conservative approach, but nonetheless one that I felt should be considered... among several others. - 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
Re: [E-devel] Evas transforms/filters/etc.
On Thu, May 1, 2008 at 7:38 PM, Jose Gonzalez [EMAIL PROTECTED] wrote: Getting back to the evas filters/transforms stuff... One other aspect that needs to be addressed has to do with the very notion Gustavo mentioned about negotiating buffer sizes that a filter/transform might need for putting results to.. and in fact this also covers things like calculating update rects when dealing with these things at the canvas level. The problem is that it may be difficult, in general, to obtain 'bounds' for these kinds of operations on objects. that's true for other parts as well, and I like raster's simplification to let's keep it to rectangles. Of course we could have any shape as clip or dirty area, but it doesn't pay off. All in all, let's keep areas as a set of rectangles. They're easier to operate and provide a good approximation for the first implementation. As you said, if calculate the proper coordinates are that difficult, then just request for whole-screen buffers and brute force :-P -- 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
Re: [E-devel] Evas transforms/filters/etc.
I wrote: 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? BTW, I should've mentioned that not only with software, but also with xrender, there are two basic, simple ways of obtaining this for 2d images using projective transforms and masks: 1. You can create a suitable gradient-like 'fade' alpha-image to use as a mask, and you can either first suitably mask the given image surface (possibly scaling the mask to 'fit' the image correctly) to a buffer image, and then use a projective transform (one which mimics a rotation around the y axis, and inverts it) on that resulting buffer image. 2. Or you can do it in one pass (no buffer images) by simultaneously transforming the given image (with the y-rotationinversion transform) and mask with the fade using a similar transform (with possibly also does scaling, as well as y-rotating and maybe inverts too, depends on how you take the fade mask to be). There are other ways.. ones that are combos of these two, and other specialty ones if you have more to work with.. But again, it's a fairly simple thing to do with just one transform on the image and a 'fade' alpha-mask image (or gradient) which may also have a transform. With a 2d vgfx based api, it's a bit more tricky and you'd still need support for projective transforms of images from that api or specialty image filters in some way - which not all 2d vgfx apis have. - 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
Re: [E-devel] Evas transforms/filters/etc.
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; -- 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
Re: [E-devel] Evas transforms/filters/etc.
Let me give some further thoughts on your proposed api: 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). This has some interesting possibilities: 1. Since filters are new types of objs, they can be used to affect the canvas (as mentioned in before), as well as modifiers of objs. 2. If filters are allowed to 'filter' other filters, then one could replace your proposed function: evas_object_filter_add(filt, obj_to_filter); with one to just 'set' a filter: evas_object_filter_set(filt, obj_to_filter); and thus one could start by supporting one filter on an obj (so that filtering a filter would be disabled), and if deemed necessary could later allow for the general case. 3. The type/params method for specifying filters/properties is good for things like loadable filters, and one could have a gl-shader type with a string param named program which would accept the program defining the thing, and others for specifying values of variables. It might also be desirable to have some 'built-in' filters though which would not need to go thru the generic api above. There's one thing about this approach to filters as objs, namely the issue of things like the pos on the canvas of the filter object and its relation to the effect on the obj the filter is set on -- assuming such a thing as a filter's pos/size makes sense at all (eg. as if applied to the subimage defined by the pos/size of the filter?). This could have semantic issues with filters set on different objs, ie. if filters have absolute pos rel to the canvas when they are set on objs. In paticular since I believe an immediate mode 'obj-draw' func is important, I wonder if maybe filters set on an obj should have that its pos is interpreted rel to the target obj (instead of the canvas). Alternatively, assuming pos/size makes sense for a given filter, filters set on an obj could be taken as always 'at' the obj's origin, and of size equal to the obj's.. or some mixture of the two.. or what? Is it worth it to consider such things as the size and pos of a filter 'set' on an object? - 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
Re: [E-devel] Evas transforms/filters/etc.
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? - 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
Re: [E-devel] Evas transforms/filters/etc.
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; Also, if you did want to go thru a 'blur', you'd probably want to do this first... depends on just what effect you want to achieve. - 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
Re: [E-devel] Evas transforms/filters/etc.
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). 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). - 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
Re: [E-devel] Evas transforms/filters/etc.
I wrote: This wouldn't really have any impact with the use of 'native surfaces' - well, depends on how wide the interpretation of such. All the engines - with the singular exeption of the gl one - use native surfaces to do the rendering to, in one way or another. That may be an exaggeration of the 'native surface' term though (for image objects). For example, the software-x11 engine *could* be thought of as having x11 pixmaps as 'native surfaces', though in fact it really uses argb buffers to render to (whose pixels are eventually put on the dst drawable thru various possible steps). It does depend on how wide one allows the interpretation of 'native surfaces - for image objects' to be.. and wether we think of them as 'native' to the (primary) rendering backend, or to the dst display target. - 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
Re: [E-devel] Evas transforms/filters/etc.
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 cpugpu 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
Re: [E-devel] Evas transforms/filters/etc.
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
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: Ah, I'd like to write a small prototype of this idea. It would get an ARGB buffer, get the filters as a linked list/array negotiate buffers and then process, giving the output as another ARGB buffer to check the results. Then modify this to add hardware accelerated surfaces (OpenGL). Filtes would be rotation, shear and blur since they're easier to work and can do lots of the simulation. But if someone feels in the mood to do so before, keep me informed. That would be a good exercise. But, don't you want to hear the rest of my philosophical commentaries? :) Yes I do, and actually they're very interesting at least. But I fear I'll not have the time to go and reply them as I'd like. Well, since you find philosophical speculations interesting, let me throw another bit of it at you before continuing with this filters stuff (mind you there are still a lot of things here that I think need to be looked into). :) We've mentioned the semantic interpretation of these 'surface' filters acting on an object as _functionally_ equivalent to first rendering the object to a buffer 'surface' and having the filter act on that surface... Ok, how about we make this former action available thru the evas api - ie. have an api func that allows for one to render an evas object to an evas image object, say of the form: void evas_object_draw(obj, dst_im_obj, x, y, w, h); or something like that. This would be an immediate-mode call, with the semantics being that the obj is drawn in its current state to the dst_im_obj's data surface, ie. composite the obj with whatever the state of the dst image surface (which can be argb data, a gl texture, an xrender pict, etc). This would open up a whole new world of immediate-mode drawing abilities to evas which haven't really been explored so far, as well as providing a user-level buffer mechanism... It can be used in many ways for many kinds of things... eg. it could be used in conjunction with smart objs with render-pre/post smart-class funcs to obtain all sorts of interesting new kinds of object types that combine elements of both immediate-mode and retained-mode gui and design/composition aspects. It can be used to cache the results of complex gfx constructs (like results of filters), to create animations that involve things like motion-blur, to And if one's clever enough, one could even find ways to add this kind of stuff to edje. PS. This is fairly easy to do right now in evas, except with the gl engine, since one'd need to draw to gl textures and there's no code in evas right now to do that. So, your work on the gl filters stuff could actually be very useful for that (among other things). PPS. You mentioned that Filters would be rotation, shear and blur since they're easier to work and can do lots of the simulation. Ummm... rotation and shear are both just specific examples of affine transformations.. but anyway, what do you mean by 'can do lots of the simulation'? Simulation of what? - 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
Re: [E-devel] Evas transforms/filters/etc.
We've mentioned the semantic interpretation of these 'surface' filters acting on an object as _functionally_ equivalent to first rendering the object to a buffer 'surface' and having the filter act on that surface... Ok, how about we make this former action available thru the evas api - ie. have an api func that allows for one to render an evas object to an evas image object, say of the form: void evas_object_draw(obj, dst_im_obj, x, y, w, h); or something like that. This would be an immediate-mode call, with the semantics being that the obj is drawn in its current state to the dst_im_obj's data surface, ie. composite the obj with whatever the state of the dst image surface (which can be argb data, a gl texture, an xrender pict, etc). Actually, a better form for this might be: void evas_object_draw(Evas_Object *obj, Evas_Object *im, Evas_Coord x, Evas_Coord y, Evas_Rectangle *clip); This form is useful when the src obj has a transform since the src 'origin' can be positioned at the dst image x,y coords, and the drawing restricted to the specified dst im clip region (if the clip is there, or over the whole image surface area if not). - 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
Re: [E-devel] Evas transforms/filters/etc.
As usual, not much time but here it goes: On Tue, Apr 22, 2008 at 5:47 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: Ah, I'd like to write a small prototype of this idea. It would get an ARGB buffer, get the filters as a linked list/array negotiate buffers and then process, giving the output as another ARGB buffer to check the results. Then modify this to add hardware accelerated surfaces (OpenGL). Filtes would be rotation, shear and blur since they're easier to work and can do lots of the simulation. But if someone feels in the mood to do so before, keep me informed. That would be a good exercise. But, don't you want to hear the rest of my philosophical commentaries? :) Yes I do, and actually they're very interesting at least. But I fear I'll not have the time to go and reply them as I'd like. Well, since you find philosophical speculations interesting, let me throw another bit of it at you before continuing with this filters stuff (mind you there are still a lot of things here that I think need to be looked into). :) We've mentioned the semantic interpretation of these 'surface' filters acting on an object as _functionally_ equivalent to first rendering the object to a buffer 'surface' and having the filter act on that surface... Ok, how about we make this former action available thru the evas api - ie. have an api func that allows for one to render an evas object to an evas image object, say of the form: void evas_object_draw(obj, dst_im_obj, x, y, w, h); or something like that. This would be an immediate-mode call, with the semantics being that the obj is drawn in its current state to the dst_im_obj's data surface, ie. composite the obj with whatever the state of the dst image surface (which can be argb data, a gl texture, an xrender pict, etc). This would open up a whole new world of immediate-mode drawing abilities to evas which haven't really been explored so far, as well as providing a user-level buffer mechanism... It can be used in many ways for many kinds of things... eg. it could be used in conjunction with smart objs with render-pre/post smart-class funcs to obtain all sorts of interesting new kinds of object types that combine elements of both immediate-mode and retained-mode gui and design/composition aspects. It can be used to cache the results of complex gfx constructs (like results of filters), to create animations that involve things like motion-blur, to And if one's clever enough, one could even find ways to add this kind of stuff to edje. PS. This is fairly easy to do right now in evas, except with the gl engine, since one'd need to draw to gl textures and there's no code in evas right now to do that. So, your work on the gl filters stuff could actually be very useful for that (among other things). Yes, that's something good to have and it's basically a code refactor of the evas_render.c. As usual, I'm not sure of the impact this would cause on NATIVE surfaces and their mixing... it would be interesting to know the results of rendering with XRender to a GL surface, I wonder if it's even possible. Maybe we should have a way to say use native or use software and user would be responsible for doing that. PPS. You mentioned that Filters would be rotation, shear and blur since they're easier to work and can do lots of the simulation. Ummm... rotation and shear are both just specific examples of affine transformations.. but anyway, what do you mean by 'can do lots of the simulation'? Simulation of what? simulation of cooperative and non-cooperative filters. As you said shear and rotation could use the same affine transformation, thus being cooperative (avoiding intermediate buffer), while shear and blur wouldn't. We could do tests like: - shear + rotation; - shear + blur; - shear + blur + rotation; that's lots of simulation I'm talking... sometimes I exagerate :-) -- 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
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: PS. This is fairly easy to do right now in evas, except with the gl engine, since one'd need to draw to gl textures and there's no code in evas right now to do that. So, your work on the gl filters stuff could actually be very useful for that (among other things). Yes, that's something good to have and it's basically a code refactor of the evas_render.c. As usual, I'm not sure of the impact this would No need for much of that, though what would be best is to redo most of the image internals, and other obj rendering calls.. needs to be done anyway. cause on NATIVE surfaces and their mixing... it would be interesting to know the results of rendering with XRender to a GL surface, I wonder if it's even possible. Maybe we should have a way to say use native or use software and user would be responsible for doing that. This wouldn't really have any impact with the use of 'native surfaces' - well, depends on how wide the interpretation of such. All the engines - with the singular exeption of the gl one - use native surfaces to do the rendering to, in one way or another. The update buffer images that objs are rendered to then get put on the dst display target. For the gl engine, image obj data is still held in gl textures, so one'd need to be able to render to those. Mixing gl and xrender? Well, depends how.. If you mean use gl to do filters or such, then you can get a texture from the pixmap associated with the xrender pictures that are used internally by the xrender engine to hold image data, and use gl to draw to the texture. Or do everything in software and put the result on the picture's pixmap as is now done for some things. Xrender supports projective transforms, and allows for certain filters, convolution matrices, which can even be used to, badly, mimic blurs for example. I can't begin to imagine how the idea of rendering with xrender to a gl surface could possibly come up.. except in a really wild interpretation of 'native surfaces'. PPS. You mentioned that Filters would be rotation, shear and blur since they're easier to work and can do lots of the simulation. Ummm... rotation and shear are both just specific examples of affine transformations.. but anyway, what do you mean by 'can do lots of the simulation'? Simulation of what? simulation of cooperative and non-cooperative filters. As you said shear and rotation could use the same affine transformation, thus being cooperative (avoiding intermediate buffer), while shear and blur wouldn't. We could do tests like: - shear + rotation; - shear + blur; - shear + blur + rotation; that's lots of simulation I'm talking... sometimes I exagerate :-) Ahhh.. Ok, I see what you mean. - 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
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: On Mon, Apr 21, 2008 at 1:04 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Jose, I'm running out of time to reply to all of these ideas, I expect to get back some development time after the company I started start to calm down on the real world side (we were getting infrastructure and like, phone, network, ...). But I really fear to loose all these ideas. I know we have mail archive, but it would help a lot if one (you, others) could move this to Wiki and do some structure, much like Dresb and I did for some ideas. Then people can check when we're about to start working on it. What do you think? Ah, I'd like to write a small prototype of this idea. It would get an ARGB buffer, get the filters as a linked list/array negotiate buffers and then process, giving the output as another ARGB buffer to check the results. Then modify this to add hardware accelerated surfaces (OpenGL). Filtes would be rotation, shear and blur since they're easier to work and can do lots of the simulation. But if someone feels in the mood to do so before, keep me informed. That would be a good exercise. But, don't you want to hear the rest of my philosophical commentaries? :) - 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
Re: [E-devel] Evas transforms/filters/etc.
On Mon, Apr 21, 2008 at 12:28 PM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: On Mon, Apr 21, 2008 at 1:04 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Jose, I'm running out of time to reply to all of these ideas, I expect to get back some development time after the company I started start to calm down on the real world side (we were getting infrastructure and like, phone, network, ...). But I really fear to loose all these ideas. I know we have mail archive, but it would help a lot if one (you, others) could move this to Wiki and do some structure, much like Dresb and I did for some ideas. Then people can check when we're about to start working on it. What do you think? Ah, I'd like to write a small prototype of this idea. It would get an ARGB buffer, get the filters as a linked list/array negotiate buffers and then process, giving the output as another ARGB buffer to check the results. Then modify this to add hardware accelerated surfaces (OpenGL). Filtes would be rotation, shear and blur since they're easier to work and can do lots of the simulation. But if someone feels in the mood to do so before, keep me informed. That would be a good exercise. But, don't you want to hear the rest of my philosophical commentaries? :) Yes I do, and actually they're very interesting at least. But I fear I'll not have the time to go and reply them as I'd like. -- 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
Re: [E-devel] Evas transforms/filters/etc.
So, what kind of api should be provided for 'filters for evas objects'? And how can general/loadable such filters be defined and obtained? Gustavo has given one possible suggestion (still needs the issue of general/loadable ones addressed, and may want to replace the 'set' with an 'add', or even an 'append/pre-pend' and others). Does anyone else have another? No other suggestions or comments yet? :) Before I suggest some possible approaches here (and frankly I'm torn between several - ranging from conservative to fairly radical ones), let me make some further comments on this.. just for fun. I've mentioned before that one needs to have strict typing of 'filters' that operate on evas objects, and that one type that can be taken to apply to all renderable objects are those filters which operate on image surfaces - ie. which are functionally equivalent to first rendering the obj to a buffer surface and then applying the filter to that (and eventually compositing the buffer surface to a dst surface). Let's agree to call such filters surface-filters. We know several such that are commonly used - blur, bumpmap, convolution kernel derived, simple color modifiers, etc.. and one other kind that's often found are the simple 2D geometric-transform ones. We can define these from a given 3x2 matrix (normally used to define affine transformations), or more generally from a 3x3 matrix (for projective transforms of 2D space). However, given say a 3x2 matrix, one can also define geometric transformations on 'vgfx' kinds of 'objects' by operating on their vertex data, and lets call such kinds of filters vertex-filters. If we're given a 'vgfx' kind of evas object - say a polygon or a rectangle, we may then consider 'geometric transforms' (from say a given affine 3x2 matrix) via these two different kinds of filters, the surface and the vertex ones... The results will not always be the same. Should one also consider these kinds of vertex filters for evas objects which have some 'vector' aspect (eg. for rect objs, or for poly objs)? And if so, how should one express these two different types of filters via the api? You might say: No. Who cares... evas is mostly a raster based canvas lib.. or at least that's the most commonly used object - image objects... Unfortunately, evas image objects are not really like raster surfaces at all.. in fact, they behave more like rectangles which have been given an image as a fill pattern (or fill texture) which is set to a repeat extend (or spread) mode by default! So, should one consider these kinds of vertex filters in evas, or not? I'll give you my answer to that: NO, I don't think one should. I don't think they're needed or desirable for most of the things that people want to do (but I won't go into details as to why I say that for now). PS. Here's a distantly related issue though: One of the most common things that people want to do with images is to rotate them (possibly in a 3D perspective way), flip them, blur them, etc. How can one make it easy to express such things for evas image objs (with filters) via the api? I'll give you my own partial answer to this as well - an answer that isn't really mine but rather is from a suggestion due to raster, and that is to: Add a fill policy flag with two possible values, say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. The former (extend) is the current behavior, wherein an image is scaled to the specified fill size and then that fill extends (from the specified fill origin) to cover the image object size (repeating only for now), ie. image objects act like rectangles with the image itself as a fill pattern for the rect (the object region). The latter (scale) fill policy will ignore any fill properties and instead the image will be scaled to fill the image object size, ie. the image object now acts like a surface which has the image scaled to fit. This makes it very easy to deal with most uses of images where one wants to simply transform an image in a certain way, and not worry about fill pattern sizes, transforms, extend modes, origins, and also object transforms - ie. when one wants an image obj to be like an image, not like a rect with an image as fill texture. For example, if you wanted to say rotate an image, or just blur an image, ... then with the current semantics of image objs you'd have several ways of setting a filter on the image obj and/or on the fill, as well as setting particular fill sizes and origins and obj sizes... all cumbersome and inefficient.. one really just wants to transform or blur the image obj and be done with it - and that's what such a new fill policy would allow.. for image objects to behave like image surfaces (subject possibly first to a scaling of the image to the object size). - This SF.net
Re: [E-devel] Evas transforms/filters/etc.
PS. Here's a distantly related issue though: One of the most common things that people want to do with images is to rotate them (possibly in a 3D perspective way), flip them, blur them, etc. How can one make it easy to express such things for evas image objs (with filters) via the api? I'll give you my own partial answer to this as well - an answer that isn't really mine but rather is from a suggestion due to raster, and that is to: Add a fill policy flag with two possible values, say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. The former (extend) is the current behavior, wherein an image is scaled to the specified fill size and then that fill extends (from the specified fill origin) to cover the image object size (repeating only for now), ie. image objects act like rectangles with the image itself as a fill pattern for the rect (the object region). The latter (scale) fill policy will ignore any fill properties and instead the image will be scaled to fill the image object size, ie. the image object now acts like a surface which has the image scaled to fit. This makes it very easy to deal with most uses of images where one wants to simply transform an image in a certain way, and not worry about fill pattern sizes, transforms, extend modes, origins, and also object transforms - ie. when one wants an image obj to be like an image, not like a rect with an image as fill texture. For example, if you wanted to say rotate an image, or just blur an image, ... then with the current semantics of image objs you'd have several ways of setting a filter on the image obj and/or on the fill, as well as setting particular fill sizes and origins and obj sizes... all cumbersome and inefficient.. one really just wants to transform or blur the image obj and be done with it - and that's what such a new fill policy would allow.. for image objects to behave like image surfaces (subject possibly first to a scaling of the image to the object size). I should've added that such an addition is not, strictly speaking, required... especially if one restricts filters/transforms to be of surface types - it'd just make things a bit simpler and more efficient for everyone. - 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
Re: [E-devel] Evas transforms/filters/etc.
On Sun, Apr 20, 2008 at 5:19 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: PS. Here's a distantly related issue though: One of the most common things that people want to do with images is to rotate them (possibly in a 3D perspective way), flip them, blur them, etc. How can one make it easy to express such things for evas image objs (with filters) via the api? I'll give you my own partial answer to this as well - an answer that isn't really mine but rather is from a suggestion due to raster, and that is to: Add a fill policy flag with two possible values, say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. The former (extend) is the current behavior, wherein an image is scaled to the specified fill size and then that fill extends (from the specified fill origin) to cover the image object size (repeating only for now), ie. image objects act like rectangles with the image itself as a fill pattern for the rect (the object region). The latter (scale) fill policy will ignore any fill properties and instead the image will be scaled to fill the image object size, ie. the image object now acts like a surface which has the image scaled to fit. This makes it very easy to deal with most uses of images where one wants to simply transform an image in a certain way, and not worry about fill pattern sizes, transforms, extend modes, origins, and also object transforms - ie. when one wants an image obj to be like an image, not like a rect with an image as fill texture. For example, if you wanted to say rotate an image, or just blur an image, ... then with the current semantics of image objs you'd have several ways of setting a filter on the image obj and/or on the fill, as well as setting particular fill sizes and origins and obj sizes... all cumbersome and inefficient.. one really just wants to transform or blur the image obj and be done with it - and that's what such a new fill policy would allow.. for image objects to behave like image surfaces (subject possibly first to a scaling of the image to the object size). I should've added that such an addition is not, strictly speaking, required... especially if one restricts filters/transforms to be of surface types - it'd just make things a bit simpler and more efficient for everyone. Jose, I'm running out of time to reply to all of these ideas, I expect to get back some development time after the company I started start to calm down on the real world side (we were getting infrastructure and like, phone, network, ...). But I really fear to loose all these ideas. I know we have mail archive, but it would help a lot if one (you, others) could move this to Wiki and do some structure, much like Dresb and I did for some ideas. Then people can check when we're about to start working on it. What do you think? -- 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
Re: [E-devel] Evas transforms/filters/etc.
On Mon, 21 Apr 2008 01:04:55 -0300 Gustavo Sverzut Barbieri [EMAIL PROTECTED] babbled: On Sun, Apr 20, 2008 at 5:19 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: PS. Here's a distantly related issue though: One of the most common things that people want to do with images is to rotate them (possibly in a 3D perspective way), flip them, blur them, etc. How can one make it easy to express such things for evas image objs (with filters) via the api? I'll give you my own partial answer to this as well - an answer that isn't really mine but rather is from a suggestion due to raster, and that is to: Add a fill policy flag with two possible values, say FILL_POLICY_EXTEND and FILL_POLICY_SCALE. The former (extend) is the current behavior, wherein an image is scaled to the specified fill size and then that fill extends (from the specified fill origin) to cover the image object size (repeating only for now), ie. image objects act like rectangles with the image itself as a fill pattern for the rect (the object region). The latter (scale) fill policy will ignore any fill properties and instead the image will be scaled to fill the image object size, ie. the image object now acts like a surface which has the image scaled to fit. This makes it very easy to deal with most uses of images where one wants to simply transform an image in a certain way, and not worry about fill pattern sizes, transforms, extend modes, origins, and also object transforms - ie. when one wants an image obj to be like an image, not like a rect with an image as fill texture. For example, if you wanted to say rotate an image, or just blur an image, ... then with the current semantics of image objs you'd have several ways of setting a filter on the image obj and/or on the fill, as well as setting particular fill sizes and origins and obj sizes... all cumbersome and inefficient.. one really just wants to transform or blur the image obj and be done with it - and that's what such a new fill policy would allow.. for image objects to behave like image surfaces (subject possibly first to a scaling of the image to the object size). I should've added that such an addition is not, strictly speaking, required... especially if one restricts filters/transforms to be of surface types - it'd just make things a bit simpler and more efficient for everyone. Jose, I'm running out of time to reply to all of these ideas, I expect to get back some development time after the company I started start to calm down on the real world side (we were getting infrastructure and like, phone, network, ...). But I really fear to loose all these ideas. I know we have mail archive, but it would help a lot if one (you, others) could move this to Wiki and do some structure, much like Dresb and I did for some ideas. Then people can check when we're about to start working on it. What do you think? I think that's an excellent idea. :) -- - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
On Mon, Apr 21, 2008 at 1:04 AM, Gustavo Sverzut Barbieri [EMAIL PROTECTED] wrote: Jose, I'm running out of time to reply to all of these ideas, I expect to get back some development time after the company I started start to calm down on the real world side (we were getting infrastructure and like, phone, network, ...). But I really fear to loose all these ideas. I know we have mail archive, but it would help a lot if one (you, others) could move this to Wiki and do some structure, much like Dresb and I did for some ideas. Then people can check when we're about to start working on it. What do you think? Ah, I'd like to write a small prototype of this idea. It would get an ARGB buffer, get the filters as a linked list/array negotiate buffers and then process, giving the output as another ARGB buffer to check the results. Then modify this to add hardware accelerated surfaces (OpenGL). Filtes would be rotation, shear and blur since they're easier to work and can do lots of the simulation. But if someone feels in the mood to do so before, keep me informed. -- 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
Re: [E-devel] Evas transforms/filters/etc.
This is the kind of thing that makes 'chaining' of arbitrary filters a problem unless very strict semantic rules are followed, and an api used which is able to naturally represent those rules. I'll continue this a bit later, but please do jump in with comments or whatnot if you see fit. In order to get a filter api that provides an un-ambiguous, intuitive interpretation for things, we thus need to separate this from the existing 'clipping' api - even if the 'filters' one might be similar, it still really needs to be separate (it'll also allow for greater flexibility if desired). One also really needs to make sure that the 'filters' are typed sufficiently so that it's clear that one's dealing with filters that modify a given object type, or that modify 'surfaces', etc. (of course one can consider rendering an object as a kind of filter on surfaces, with the obj to be rendered to the surface as providing part of the data that defines such a surface filter). Without that, we have the general kind of ambiguity faced with certain common filter notions like geometric transforms or coloring, where one has to decide somehow whether to interpret the effect of the filter as acting on a buffer-surface rendering of the object, or otherwise.. and this is not something unique to smart-objs. For example, in something like transf blur transf polygon the first applied transform could well be interpreted as acting on vertex data, but the last applied one would likely need to be done on surface data - ie. transform a buffer surface that holds the result of blurring a rendered poly (until someone comes up with vertex data for blurry-polygons). Consider implementing the general case of this kind of thing, with arbitrary chains, with loadable filters, with any object... unless you have strict typing mechanisms and composition rules. So long as we maintain strict typing of filters, and semantic rules for filter composition, we have few problems.. otherwise, one has to be more careful in order to resolve possible ambiguities. And as soon as one starts to allow for general/loadable kinds of filters, then one really *has* to have strict typing notions. Whether it's just restricting things to abstract geometric transforms and surface (ie. image) effects, or something more general, one needs to know exactly what one is working with.. a vague 'filters for evas objects.. We can do anything!' idea is just going to lead to an absurd mess. So, what kind of api should be provided for 'filters for evas objects'? And how can general/loadable such filters be defined and obtained? Gustavo has given one possible suggestion (still needs the issue of general/loadable ones addressed, and may want to replace the 'set' with an 'add', or even an 'append/pre-pend' and others). Does anyone else have another? - 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
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: PS. Some here would like to have ultimately flexible 'filters' defined via some cpugpu 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 Ok, sure. But how does one implement the filters.. how do you do it so that the filters will then work with any obj, any evas, etc. One can imagine 'filters' as engine dependent modules of some sort, and then you can use whatever for implementing each.. gl shaders, software span functions, etc. Generally speaking though, most of this will work for filters that will apply to image surfaces of given types. One can also try and have an even more abstract gfx 'api' like shading languages provide, and map such to the rendering backends - but that's a lot more work. it. If you want to be dependent on GL, do it on your code, use it from your application. That was the whole point of at least having 'native surfaces' for image objs - so one could render to such surfaces via whatever specific apis one wants that could support rendering to those. Then, if one wants to use gl-shaders to do stuff on a gl texture.. great.. One could even use such gl stuff on an xrender native surface by getting a texture from the pixmap associated with a picture, etc. Lots of possibilities available for quite custom rendering to such buffers (and best utilized as part of smart objs with render-pre/post functions, and of course also via a more direct dst surface rendering mechanism). 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): Ok, but before we go on with this, let's note that there are (at least) three different ways one can imagine things like filters in evas: 1. One can consider filters as certain evas objects that modify the rendered region 'beneath' them (ie. in stacking order, over some region they define). This is what things like mini/magni-fication filters do, or say a blur obj that blurs the region beneath where a such an object would be placed (BTW, Hisham once implemented something like that for evas, for the software engines only.. or at least I seem to recall something like that long ago). This is potentially very interesting. 2. One can consider filters as certain modifiers which affect how a given evas object will be rendered. Now of course one can think of just about anything that way (including move, resize, color, whatnot) and it's not always useful to express everything that way.. but as you mention, one should leave open the ability to define new such kinds of filters. These are somewhat wider in scope than the above (1) since one can potentially have filters that affect only certain kinds of objects (eg. text-styles, or even fonts, can be considered as filters on text objs.. some may or may not make much sense on other types of objs). In general, for a given set of structured data (objs), we can have 'filters' that are natural to it, and some that are not (but may be for others). This is in part some of the problem we have with things like smart objs.. we even have an ambiguity with simple things like setting the color of such objs - right now we usually color each member (not much else we can do), but one could also want to color the obj as a whole (eg. as if the smart obj were rendered to a buffer evas and that image were colored). The same kind of 'issue' will come up with even more general 'filters' - even those that are geometric or raster-image- modifiers in nature. 3. One can consider filters as part of an immediate-mode api that allows one to affect other immediate-mode rendering primitives, and use such for custom rendering (to native surfaces say). There, one's able to use whatever may already exist that's appropriate. I'll try and get back to the rest of your reply once I get a chance to sleep some - but much of it is a lot like what I also had in mind. :)
Re: [E-devel] Evas transforms/filters/etc.
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. 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. Gustavo then mentioned that no, it was to be thru a similar mechanism, but not actually as clip objects. 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... 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. jose. PS. Some here would like to have ultimately flexible 'filters' defined via some cpugpu 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. - 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
Re: [E-devel] Evas transforms/filters/etc.
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 cpugpu 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
Re: [E-devel] Evas transforms/filters/etc.
Carsten wrote: don't be too excited... it will take time to have someone to do that. What! I thought you were working on this full-steam ahead.. Carsten said that's what you were doing! You're going to have to speak with him about it.. slap him around a bit and throw some frozen fish at him, it should do the trick. i did? where? :) i am thinking about this still - though right now i think Nowhere, it was an exaggeration to get Gustavo and you going on this. :) rotation should be separate to filters as such, BUT i dont preclude filters ALSO doing rotation/shear (ie matrix transforms). simple rotation without a filter is probably needed and i'd much sooner address that than filters, but next up is filters. i just don't see a better way to do it other than use the same kind of api that clippers use - clippers are in effect very simple filters on their own. you could have optimised paths, but as such you likely are going to have to render to intermediate buffers, like it or not. :) As to the particulars of this transforms/filters stuff... well, that one has to use buffers for some things is not an issue. Anyway... Since you're still thinking about all this, and since this has already been discussed at bossa, I'll drop the issue. - 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
Re: [E-devel] Evas transforms/filters/etc.
On Tue, 15 Apr 2008 15:17:57 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: i did? where? :) i am thinking about this still - though right now i think Nowhere, it was an exaggeration to get Gustavo and you going on this. :) h! drat. so i'm still perfectly sane. DAMN IT! i thought i was going mad! :) filters on their own. you could have optimised paths, but as such you likely are going to have to render to intermediate buffers, like it or not. :) As to the particulars of this transforms/filters stuff... well, that one has to use buffers for some things is not an issue. 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 wanting to be able to optimise filter paths and possible merge them (eg a re-color filter than changes contrast for example combined with a rotation filter instead of needing 2 intermediate buffers/stages, merge them if the rotation filter can also change contra while rotating). -- - 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 enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: PS. I'd just set a 4x4 proj transf (you can get some funky curved stuff that way) and have utility functions for generating such in various ways (eg. for obtaining one from four dst points, for composing two transforms, etc.). Ok, trying to reply to the torrent of ideas from you ;-) No torrent of ideas, just simple basic things that I've already run across and thought might help for you to keep in mind. - 4x4 proj transf = good, one idea that we were considering. That's very nice for we. :) - filter chaining: needs evaluation on good api to negotiate between filters, those that can be done within the matrix (ie: just add to transf matrix), do, others will require the intermediate buffer and will operate on it. So Rotate+Translate+Blur would generate Rotate+Translate in matrix, output a temporary buffer that blur would operate on. This may be suboptimal, but is very easy to work on. - rely on hw-acceleration (shaders and like): it's easy, it's almost everywhere and people are gaining market share by naively using it. We don't even allow users to use it. If you have or not such great hardware, you're unable to use it today. So why not expose this and let users use their hardware? Also, we can still support some of these in software (ie: matrix transf) easily, while others we can simple ignore.Most users (ie: E17) will try to keep with supported-everywhere, avoiding things that might depend on hardware. But others (ie: Rage) could try to use these fancy effects, since they know most of their users will have such hardware. Also, we could use Sure, and that's why things like 'native surfaces' or other methods for custom rendering would be useful - so that people can do those kinds of things if they wish. Gallium3D or even go with LLVM directly to get some kind of JIT and have software-only implementation that is highly optimized, without having to care much about it ourselves. All in all, this filter thing is all about exposing some of hardware acceleration without having to explicitly implement it in Evas (as it's done now for things like YUV-RGB conversion, Scale, Colorize, Fade, ...). Actually I was about to go with this individual implementation, like adding evas_object_rotate() and like, but raster and others convinced me that going with a generic filter implementation would be more extensible. Going with super-fast custom case for each of this will span a huge number of function implementations (ie: rotate solid-solid, rotate transp-solid, rotate transp+alpha-solid, ... all of these for C, MMX, SSE, SSE2, Altivec, 16bpp, ...), since this is non-sense for such things that are barely used, let's make it more generic and have the optimizations to be done elsewhere. Well, that sounds great! Looking forward to seeing this finally in evas. :) - 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
Re: [E-devel] Evas transforms/filters/etc.
On Sun, Apr 13, 2008 at 3:58 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: PS. I'd just set a 4x4 proj transf (you can get some funky curved stuff that way) and have utility functions for generating such in various ways (eg. for obtaining one from four dst points, for composing two transforms, etc.). Ok, trying to reply to the torrent of ideas from you ;-) No torrent of ideas, just simple basic things that I've already run across and thought might help for you to keep in mind. that was a joke because you replied about 3 times to yourself, adding more ideas :-) - 4x4 proj transf = good, one idea that we were considering. That's very nice for we. :) you mean because of me? Or because of others? At least raster, if you ask him, he have tons of ideas on how to do things, he have considered almost every case I wondered and the problems come from here: he wants to implement the final super-uber solution to fix them all and he never have time to do it. The only thing that I added to most things were simpler solution to fix part of the problem and improve this later :-P - filter chaining: needs evaluation on good api to negotiate between filters, those that can be done within the matrix (ie: just add to transf matrix), do, others will require the intermediate buffer and will operate on it. So Rotate+Translate+Blur would generate Rotate+Translate in matrix, output a temporary buffer that blur would operate on. This may be suboptimal, but is very easy to work on. - rely on hw-acceleration (shaders and like): it's easy, it's almost everywhere and people are gaining market share by naively using it. We don't even allow users to use it. If you have or not such great hardware, you're unable to use it today. So why not expose this and let users use their hardware? Also, we can still support some of these in software (ie: matrix transf) easily, while others we can simple ignore.Most users (ie: E17) will try to keep with supported-everywhere, avoiding things that might depend on hardware. But others (ie: Rage) could try to use these fancy effects, since they know most of their users will have such hardware. Also, we could use Sure, and that's why things like 'native surfaces' or other methods for custom rendering would be useful - so that people can do those kinds of things if they wish. AFAIU, the idea is already there, just need finishing? (About that other mail) Gallium3D or even go with LLVM directly to get some kind of JIT and have software-only implementation that is highly optimized, without having to care much about it ourselves. All in all, this filter thing is all about exposing some of hardware acceleration without having to explicitly implement it in Evas (as it's done now for things like YUV-RGB conversion, Scale, Colorize, Fade, ...). Actually I was about to go with this individual implementation, like adding evas_object_rotate() and like, but raster and others convinced me that going with a generic filter implementation would be more extensible. Going with super-fast custom case for each of this will span a huge number of function implementations (ie: rotate solid-solid, rotate transp-solid, rotate transp+alpha-solid, ... all of these for C, MMX, SSE, SSE2, Altivec, 16bpp, ...), since this is non-sense for such things that are barely used, let's make it more generic and have the optimizations to be done elsewhere. Well, that sounds great! Looking forward to seeing this finally in evas. :) don't be too excited... it will take time to have someone to do that. Also, we finally have a release plan, no fixed dates yet, but the order is already there: EET, Embryo, Evas, Edje and then E (probably entrance will go earlier?)... so Evas is very close in the list and might get frozen soon, this would have to go in a branch and wait for the next coding window to get in. -- 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
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: - 4x4 proj transf = good, one idea that we were considering. That's very nice for we. :) you mean because of me? Or because of others? At least raster, if you ask him, he have tons of ideas on how to do things, he have considered almost every case I wondered and the problems come from here: he wants to implement the final super-uber solution to fix them all and he never have time to do it. The only thing that I added to most things were simpler solution to fix part of the problem and improve this later :-P Is that right.. Well now raster you evil man!! :) Well, that sounds great! Looking forward to seeing this finally in evas. :) don't be too excited... it will take time to have someone to do that. What! I thought you were working on this full-steam ahead.. Carsten said that's what you were doing! You're going to have to speak with him about it.. slap him around a bit and throw some frozen fish at him, it should do the trick. - 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
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: Filters will just be filtered by filters, so it's like SO1(O1-F1)-F2-F3. Object O1 that is filtered by F1 and inside Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 will get these 3 filters. Example, F1 could be blur, while F2 be rotation and F3 be scale. BTW, this is not going to work well at all with things like projective transforms (eg. ones mimmicking 3D rotations) if you want to preserve perspective and such. Because you'd need to further translate the smart members by their position rel to the smart parent and other such complications. Your best bet here is to either let the members decide what to do with the parent transform, or to 'render' the untransformed smart-obj to a buffer and transform that. - 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
Re: [E-devel] Evas transforms/filters/etc.
I wrote: Gustavo wrote: Filters will just be filtered by filters, so it's like SO1(O1-F1)-F2-F3. Object O1 that is filtered by F1 and inside Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 will get these 3 filters. Example, F1 could be blur, while F2 be rotation and F3 be scale. BTW, this is not going to work well at all with things like projective transforms (eg. ones mimmicking 3D rotations) if you want to preserve perspective and such. Because you'd need to further translate the smart members by their position rel to the smart parent and other such complications. Your best bet here is to either let the members decide what to do with the parent transform, or to 'render' the untransformed smart-obj to a buffer and transform that. Not that it's any less problematic with affine 2D ones in general.. But again, unless you want to dictate the policy that transformed smart objs should be rendered untransf to a buffer and then that result transformed, you may want instead to have smart-class functions for 'setting' a transform on a smart obj, similar to what's now done with move, resize. Also, if you want to split your transforms into 'commands' rotate, translate, etc. then to get 3D kinds of transforms you'll need to add axes to rotate around, or maybe aound a 3d vector (and maybe a focal distance). PS. I'd just set a 4x4 proj transf (you can get some funky curved stuff that way) and have utility functions for generating such in various ways (eg. for obtaining one from four dst points, for composing two transforms, etc.). - 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
Re: [E-devel] Evas transforms/filters/etc.
On Sat, Apr 12, 2008 at 4:53 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: I wrote: Gustavo wrote: Filters will just be filtered by filters, so it's like SO1(O1-F1)-F2-F3. Object O1 that is filtered by F1 and inside Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 will get these 3 filters. Example, F1 could be blur, while F2 be rotation and F3 be scale. BTW, this is not going to work well at all with things like projective transforms (eg. ones mimmicking 3D rotations) if you want to preserve perspective and such. Because you'd need to further translate the smart members by their position rel to the smart parent and other such complications. Your best bet here is to either let the members decide what to do with the parent transform, or to 'render' the untransformed smart-obj to a buffer and transform that. Not that it's any less problematic with affine 2D ones in general.. But again, unless you want to dictate the policy that transformed smart objs should be rendered untransf to a buffer and then that result transformed, you may want instead to have smart-class functions for 'setting' a transform on a smart obj, similar to what's now done with move, resize. Also, if you want to split your transforms into 'commands' rotate, translate, etc. then to get 3D kinds of transforms you'll need to add axes to rotate around, or maybe aound a 3d vector (and maybe a focal distance). PS. I'd just set a 4x4 proj transf (you can get some funky curved stuff that way) and have utility functions for generating such in various ways (eg. for obtaining one from four dst points, for composing two transforms, etc.). Ok, trying to reply to the torrent of ideas from you ;-) - 4x4 proj transf = good, one idea that we were considering. - filter chaining: needs evaluation on good api to negotiate between filters, those that can be done within the matrix (ie: just add to transf matrix), do, others will require the intermediate buffer and will operate on it. So Rotate+Translate+Blur would generate Rotate+Translate in matrix, output a temporary buffer that blur would operate on. This may be suboptimal, but is very easy to work on. - rely on hw-acceleration (shaders and like): it's easy, it's almost everywhere and people are gaining market share by naively using it. We don't even allow users to use it. If you have or not such great hardware, you're unable to use it today. So why not expose this and let users use their hardware? Also, we can still support some of these in software (ie: matrix transf) easily, while others we can simple ignore.Most users (ie: E17) will try to keep with supported-everywhere, avoiding things that might depend on hardware. But others (ie: Rage) could try to use these fancy effects, since they know most of their users will have such hardware. Also, we could use Gallium3D or even go with LLVM directly to get some kind of JIT and have software-only implementation that is highly optimized, without having to care much about it ourselves. All in all, this filter thing is all about exposing some of hardware acceleration without having to explicitly implement it in Evas (as it's done now for things like YUV-RGB conversion, Scale, Colorize, Fade, ...). Actually I was about to go with this individual implementation, like adding evas_object_rotate() and like, but raster and others convinced me that going with a generic filter implementation would be more extensible. Going with super-fast custom case for each of this will span a huge number of function implementations (ie: rotate solid-solid, rotate transp-solid, rotate transp+alpha-solid, ... all of these for C, MMX, SSE, SSE2, Altivec, 16bpp, ...), since this is non-sense for such things that are barely used, let's make it more generic and have the optimizations to be done elsewhere. -- 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
Re: [E-devel] Evas transforms/filters/etc.
I wrote: However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) I should add that I'm in the minority here - you, vincent, and raster (maybe many others) all think that the generic 'clipping' pipeline is the best way to go. I'd just like to see one implementation of this that works well with all engines, maps naturally (in its full generality) to real-time evas obj rendering, is easy for people to use, and has no surprises/difficulties/semantic-issues/etc. - 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
Re: [E-devel] Evas transforms/filters/etc.
On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: I wrote: However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) I should add that I'm in the minority here - you, vincent, and raster (maybe many others) all think that the generic 'clipping' pipeline is the best way to go. I'd just like to see one implementation of this that works well with all engines, maps naturally (in its full generality) to real-time evas obj rendering, is easy for people to use, and has no surprises/difficulties/semantic-issues/etc. I must say that I don't really see the difference between your two proposal. Perhaps if you can propose the set of functions that will be exported by Evas to the external developper, it will be easier to understand and discuss. -- Cedric BAIL - 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
Re: [E-devel] Evas transforms/filters/etc.
Cedric wrote: On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez wrote: I wrote: However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) I should add that I'm in the minority here - you, vincent, and raster (maybe many others) all think that the generic 'clipping' pipeline is the best way to go. I'd just like to see one implementation of this that works well with all engines, maps naturally (in its full generality) to real-time evas obj rendering, is easy for people to use, and has no surprises/difficulties/semantic-issues/etc. I must say that I don't really see the difference between your two proposal. Perhaps if you can propose the set of functions that will be exported by Evas to the external developper, it will be easier to understand and discuss. The main difference is that of avoiding the iterative 'clipping' mechanism as the single method for doing everything. What you want is something like: A clips B clips C clips D clips E clips F clips G clips H say, where H is eg. an image obj and G a transform obj and F a rect obj and E a blur filter and D a gradient obj and C a . with the result of obtaining a transformed image which is multiplied by blurred rect which is multiplied by gradient which is then composited to the dst. Also, some of these clippers may be clipping other objs. Very succint, very extensive... very likely to be difficult to optimize for simple, commom-use cases, and even more likely to not be used in this kind of arbitrary generality. Also likely to be problematic with smart objs and difficult to use for basic things.. imagine setting a trnasform on an image obj that's already had a rect set as a clip - one'd have to unset the rect clipper, set the transf as the new clipper, and set the rect as the clipper of the transform.. and that's just one example of the kinds of things that come up with this approach. I'm suggesting that one avoid this temptation, leave clipping as is for now (plain rects), and instead add separate api funcs to set a geometric trnasform, to set a mask (image or grad, no masking a mask), and to set certain kinds of 'effects' filters (blur, bumpmap, ... possibly allow for chaining these). If one wants more than this, then there are several ways to obtain things - eg. introduce a 'drawing obj' type which essentially allows for one to iterate these things by allowing one to 'add' other objs to it (much like a group obj), including ones like it, and extend masks to also be of this type. Anything beyond that should probably be the domain of custom objs that can use whatever methods/apis they have access to.. gl, shaders. whatever. But keep the core, built-in stuff simple, efficient, natural and also flexible enough to obtain more complex things if desired. - 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
Re: [E-devel] Evas transforms/filters/etc.
On Fri, Apr 11, 2008 at 4:29 PM, Jose Gonzalez [EMAIL PROTECTED] wrote: Cedric wrote: On Fri, Apr 11, 2008 at 8:35 AM, Jose Gonzalez wrote: I wrote: However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) I should add that I'm in the minority here - you, vincent, and raster (maybe many others) all think that the generic 'clipping' pipeline is the best way to go. I'd just like to see one implementation of this that works well with all engines, maps naturally (in its full generality) to real-time evas obj rendering, is easy for people to use, and has no surprises/difficulties/semantic-issues/etc. I must say that I don't really see the difference between your two proposal. Perhaps if you can propose the set of functions that will be exported by Evas to the external developper, it will be easier to understand and discuss. The main difference is that of avoiding the iterative 'clipping' mechanism as the single method for doing everything. What you want is something like: A clips B clips C clips D clips E clips F clips G clips H say, where H is eg. an image obj and G a transform obj and F a rect obj and E a blur filter and D a gradient obj and C a . with the result of obtaining a transformed image which is multiplied by blurred rect which is multiplied by gradient which is then composited to the dst. Also, some of these clippers may be clipping other objs. Very succint, very extensive... very likely to be difficult to optimize for simple, commom-use cases, and even more likely to not be used in this kind of arbitrary generality. Also likely to be problematic with smart objs and difficult to use for basic things.. imagine setting a trnasform on an image obj that's already had a rect set as a clip - one'd have to unset the rect clipper, set the transf as the new clipper, and set the rect as the clipper of the transform.. and that's just one example of the kinds of things that come up with this approach. I'm suggesting that one avoid this temptation, leave clipping as is for now (plain rects), and instead add separate api funcs to set a geometric trnasform, to set a mask (image or grad, no masking a mask), and to set certain kinds of 'effects' filters (blur, bumpmap, ... possibly allow for chaining these). Well, you misunderstood me then. Filters would behave like clippers, but not use the clipper mechs... I think I tried to say that in my email. We'd have both clippers and filters as separate lists. Clippers, in far, far, far.. future, will add some of what you want, as clip to a bitmap and get a mask, clip to a gradient and get nice fade-out of clipped items. That's what raster want to provide AFAIK. Filters will just be filtered by filters, so it's like SO1(O1-F1)-F2-F3. Object O1 that is filtered by F1 and inside Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 will get these 3 filters. Example, F1 could be blur, while F2 be rotation and F3 be scale. Of course one could implement F1 as a weird filter that uses fragment shaders to provide a fade-out effect, so eliminating the need for that in clipper. If one wants more than this, then there are several ways to obtain things - eg. introduce a 'drawing obj' type which essentially allows for one to iterate these things by allowing one to 'add' other objs to it (much like a group obj), including ones like it, and extend masks to also be of this type. Anything beyond that should probably be the domain of custom objs that can use whatever methods/apis they have access to.. gl, shaders. whatever. But keep the core, built-in stuff simple, efficient, natural and also flexible enough to obtain more complex things if desired. they will remain like this, no existing code should be influenced by these changes. -- 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.
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: The main difference is that of avoiding the iterative 'clipping' mechanism as the single method for doing everything. What you want is something like: A clips B clips C clips D clips E clips F clips G clips H say, where H is eg. an image obj and G a transform obj and F a rect obj and E a blur filter and D a gradient obj and C a . with the result of obtaining a transformed image which is multiplied by blurred rect which is multiplied by gradient which is then composited to the dst. Also, some of these clippers may be clipping other objs. Very succint, very extensive... very likely to be difficult to optimize for simple, commom-use cases, and even more likely to not be used in this kind of arbitrary generality. Also likely to be problematic with smart objs and difficult to use for basic things.. imagine setting a trnasform on an image obj that's already had a rect set as a clip - one'd have to unset the rect clipper, set the transf as the new clipper, and set the rect as the clipper of the transform.. and that's just one example of the kinds of things that come up with this approach. I'm suggesting that one avoid this temptation, leave clipping as is for now (plain rects), and instead add separate api funcs to set a geometric trnasform, to set a mask (image or grad, no masking a mask), and to set certain kinds of 'effects' filters (blur, bumpmap, ... possibly allow for chaining these). Well, you misunderstood me then. Filters would behave like clippers, but not use the clipper mechs... I think I tried to say that in my email. We'd have both clippers and filters as separate lists. Clippers, in far, far, far.. future, will add some of what you want, as clip to a bitmap and get a mask, clip to a gradient and get nice fade-out of clipped items. That's what raster want to provide AFAIK. I don't think clippers should enable that - raster and others may though. I already implemented this once.. and didn't like it. I'd separate masking as its own operation, and leave clipping as is. As far as filters having their own api funcs but incorporating both geometric transforms and various filter effects (blur, whatnot), and chainable.. that may be ok (possibly still somewhat unwarranted for most needs). Filters will just be filtered by filters, so it's like SO1(O1-F1)-F2-F3. Object O1 that is filtered by F1 and inside Smart Object SO1 that is filtered by F2 that is filtered by F3, O1 will get these 3 filters. Example, F1 could be blur, while F2 be rotation and F3 be scale. Of course one could implement F1 as a weird filter that uses fragment shaders to provide a fade-out effect, so eliminating the need for that in clipper. That is very easy to obtain via (projective) transforms and masks (image, grads, or general 'drawing objs'), without having to invoke fragment shaders. If one wants more than this, then there are several ways to obtain things - eg. introduce a 'drawing obj' type which essentially allows for one to iterate these things by allowing one to 'add' other objs to it (much like a group obj), including ones like it, and extend masks to also be of this type. Anything beyond that should probably be the domain of custom objs that can use whatever methods/apis they have access to.. gl, shaders. whatever. But keep the core, built-in stuff simple, efficient, natural and also flexible enough to obtain more complex things if desired. they will remain like this, no existing code should be influenced by these changes. What does that have to do with anything we're discussing here? - 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
[E-devel] Evas transforms/filters/etc.
Just wondering if any progress has been made on this (eg. Gustavo, Vincent, ...?), or if anyone from the SoC is planning to give it a try? If not, then maybe I'll spend a bit of time to at least get the ball rolling on this for evas.. at least get image fill-transforms (affine ones), and see about the rest later. I personally won't do a generic clipping mechanism to include obj transforms/filters/masks/... I just don't think that kind of approach is worth it in evas (I did much of this before and didn't like it then), and would personally break things up into separate transforms, masks (image objs only), and filters (and keep clipping as it pretty much is right now). Note though that any of this means dealing with a lot of the evas image internals... Cedric. :) jose. - 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
Re: [E-devel] Evas transforms/filters/etc.
On Thu, Apr 10, 2008 at 6:00 PM, Jose Gonzalez [EMAIL PROTECTED] wrote: Just wondering if any progress has been made on this (eg. Gustavo, Vincent, ...?), or if anyone from the SoC is planning to give it a try? I haven't touch my development environment for a while now. This company startup is killing all of my time, and what's left is dealing with clients and their needs :-/ Things should be back to normal in some weeks, then I plan to work at this, maybe it will be a client request, who knows! ;-) If not, then maybe I'll spend a bit of time to at least get the ball rolling on this for evas.. at least get image fill-transforms (affine ones), and see about the rest later. I personally won't do a generic clipping mechanism to include obj transforms/filters/masks/... I just don't think that kind of approach is worth it in evas (I did much of this before and didn't like it then), and would personally break things up into separate transforms, masks (image objs only), and filters (and keep clipping as it pretty much is right now). Well, what we've discussed at BossaConference, raster, cedric and others might complement/correct me here: add a mechanism similar to clip as it would accumulate various filters (so rotation + shear + ... will look fine). Make a function available for the filter to query for the output window (given these objects, what's the output bounding box), then allocate a semi-transparent buffer and blit them all there, apply the filter to this buffer when going to the end destination (output buffer). This have couple of issues, like you cannot have filtered and non-filtered interleaved, but I think this is acceptable given the easy it will bring to implementation and it should cover most of the cases. Someone need to think about how to apply it to smart objects, if we can do a automatic apply-to-all-member or provide a specific smart api for it... for clippers, usually the smart object creates an internal clipper and all members that should be clipped will be clipped to it (it's in Edje, for example). But if we create a dummy filter for the smart, then we might have lots of overhead if the implementation is naive :-/ Summary: - similar to clip; - filters provide a way to get the output window (bounding box) given a set of 'filtered' objects; - filters allocate a temporary ARGB buffer, all objects are rendered there in order, then this buffer is filtered and the output is placed at the screen (outbuf). Maybe the implementation will be smart enough and filters should also return if the image should be ARGB or RGB (ie: rotate a jpeg) and if the output have holes and should be handled as transparent or not (rotate a jpeg = transparent area, blur a jpeg = opaque area). These buffers can be GL Framebuffer Objects... - filters should work based on the output window, this will avoid holes in the output for some filters (ie: rotation). Maybe it can be flexible enough to support the other way? Does it worth to have both? - not clear on how to go with smart objects api, needs evaluation. -- 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
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: On Thu, Apr 10, 2008 at 6:00 PM, Jose Gonzalez wrote: Just wondering if any progress has been made on this (eg. Gustavo, Vincent, ...?), or if anyone from the SoC is planning to give it a try? I haven't touch my development environment for a while now. This company startup is killing all of my time, and what's left is dealing with clients and their needs :-/ Things should be back to normal in some weeks, then I plan to work at this, maybe it will be a client request, who knows! ;-) If not, then maybe I'll spend a bit of time to at least get the ball rolling on this for evas.. at least get image fill-transforms (affine ones), and see about the rest later. I personally won't do a generic clipping mechanism to include obj transforms/filters/masks/... I just don't think that kind of approach is worth it in evas (I did much of this before and didn't like it then), and would personally break things up into separate transforms, masks (image objs only), and filters (and keep clipping as it pretty much is right now). Well, what we've discussed at BossaConference, raster, cedric and others might complement/correct me here: add a mechanism similar to clip as it would accumulate various filters (so rotation + shear + ... will look fine). Make a function available for the filter to query for the output window (given these objects, what's the output bounding box), then allocate a semi-transparent buffer and blit them all there, apply the filter to this buffer when going to the end destination (output buffer). This have couple of issues, like you cannot have filtered and non-filtered interleaved, but I think this is acceptable given the easy it will bring to implementation and it should cover most of the cases. Someone need to think about how to apply it to smart objects, if we can do a automatic apply-to-all-member or provide a specific smart api for it... for clippers, usually the smart object creates an internal clipper and all members that should be clipped will be clipped to it (it's in Edje, for example). But if we create a dummy filter for the smart, then we might have lots of overhead if the implementation is naive :-/ Summary: - similar to clip; - filters provide a way to get the output window (bounding box) given a set of 'filtered' objects; - filters allocate a temporary ARGB buffer, all objects are rendered there in order, then this buffer is filtered and the output is placed at the screen (outbuf). Maybe the implementation will be smart enough and filters should also return if the image should be ARGB or RGB (ie: rotate a jpeg) and if the output have holes and should be handled as transparent or not (rotate a jpeg = transparent area, blur a jpeg = opaque area). These buffers can be GL Framebuffer Objects... - filters should work based on the output window, this will avoid holes in the output for some filters (ie: rotation). Maybe it can be flexible enough to support the other way? Does it worth to have both? - not clear on how to go with smart objects api, needs evaluation. This is exactly what I don't like.. It's complex, slow, and I feel not really needed or warranted. Most of what people really want is fairly simple - transform an object and possibly mask it with an image or gadient (itself possibly transformed), possibly with some 'effects' filter applied (pointwise or spatial), and composite with the dst surface (image objs can also have a separate fill-transfom set on them much like grad objs now allow for fill rotations). This can be done easily and efficiently via separate transforms, masks, and a certain set of 'effects' filters (blur, cmods, etc), if need be.. and avoid complexities of modifiers of modifiers of modifiers of with no clear mechanism for optimization except happy buffer land. But if everyone feels that the generalized 'clip' mechanism is the way to go.. then fine, please do carry on. - 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
Re: [E-devel] Evas transforms/filters/etc.
On Thu, 10 Apr 2008, Jose Gonzalez wrote: Just wondering if any progress has been made on this (eg. Gustavo, Vincent, ...?), or if anyone from the SoC is planning to give it a try? i won't touch that anytime soon. I'm more focused on my new toy (cross-compiling for wince) Vincent - 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
Re: [E-devel] Evas transforms/filters/etc.
On Thu, Apr 10, 2008 at 8:22 PM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: On Thu, Apr 10, 2008 at 6:00 PM, Jose Gonzalez wrote: Just wondering if any progress has been made on this (eg. Gustavo, Vincent, ...?), or if anyone from the SoC is planning to give it a try? I haven't touch my development environment for a while now. This company startup is killing all of my time, and what's left is dealing with clients and their needs :-/ Things should be back to normal in some weeks, then I plan to work at this, maybe it will be a client request, who knows! ;-) If not, then maybe I'll spend a bit of time to at least get the ball rolling on this for evas.. at least get image fill-transforms (affine ones), and see about the rest later. I personally won't do a generic clipping mechanism to include obj transforms/filters/masks/... I just don't think that kind of approach is worth it in evas (I did much of this before and didn't like it then), and would personally break things up into separate transforms, masks (image objs only), and filters (and keep clipping as it pretty much is right now). Well, what we've discussed at BossaConference, raster, cedric and others might complement/correct me here: add a mechanism similar to clip as it would accumulate various filters (so rotation + shear + ... will look fine). Make a function available for the filter to query for the output window (given these objects, what's the output bounding box), then allocate a semi-transparent buffer and blit them all there, apply the filter to this buffer when going to the end destination (output buffer). This have couple of issues, like you cannot have filtered and non-filtered interleaved, but I think this is acceptable given the easy it will bring to implementation and it should cover most of the cases. Someone need to think about how to apply it to smart objects, if we can do a automatic apply-to-all-member or provide a specific smart api for it... for clippers, usually the smart object creates an internal clipper and all members that should be clipped will be clipped to it (it's in Edje, for example). But if we create a dummy filter for the smart, then we might have lots of overhead if the implementation is naive :-/ Summary: - similar to clip; - filters provide a way to get the output window (bounding box) given a set of 'filtered' objects; - filters allocate a temporary ARGB buffer, all objects are rendered there in order, then this buffer is filtered and the output is placed at the screen (outbuf). Maybe the implementation will be smart enough and filters should also return if the image should be ARGB or RGB (ie: rotate a jpeg) and if the output have holes and should be handled as transparent or not (rotate a jpeg = transparent area, blur a jpeg = opaque area). These buffers can be GL Framebuffer Objects... - filters should work based on the output window, this will avoid holes in the output for some filters (ie: rotation). Maybe it can be flexible enough to support the other way? Does it worth to have both? - not clear on how to go with smart objects api, needs evaluation. This is exactly what I don't like.. It's complex, slow, and I feel not really needed or warranted. Most of what people really want is fairly simple - transform an object and possibly mask it with an image or gadient (itself possibly transformed), possibly with some 'effects' filter applied (pointwise or spatial), and composite with the dst surface (image objs can also have a separate fill-transfom set on them much like grad objs now allow for fill rotations). This can be done easily and efficiently via separate transforms, masks, and a certain set of 'effects' filters (blur, cmods, etc), if need be.. and avoid complexities of modifiers of modifiers of modifiers of with no clear mechanism for optimization except happy buffer land. But if everyone feels that the generalized 'clip' mechanism is the way to go.. then fine, please do carry on. If _I_ would do it, I'd do it for usage with OpenGL or other hw-accelerated systems, so this would map easily to them and would be fast. However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) -- 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
Re: [E-devel] Evas transforms/filters/etc.
Gustavo wrote: Well, what we've discussed at BossaConference, raster, cedric and others might complement/correct me here: add a mechanism similar to clip as it would accumulate various filters (so rotation + shear + ... will look fine). Make a function available for the filter to query for the output window (given these objects, what's the output bounding box), then allocate a semi-transparent buffer and blit them all there, apply the filter to this buffer when going to the end destination (output buffer). This have couple of issues, like you cannot have filtered and non-filtered interleaved, but I think this is acceptable given the easy it will bring to implementation and it should cover most of the cases. Someone need to think about how to apply it to smart objects, if we can do a automatic apply-to-all-member or provide a specific smart api for it... for clippers, usually the smart object creates an internal clipper and all members that should be clipped will be clipped to it (it's in Edje, for example). But if we create a dummy filter for the smart, then we might have lots of overhead if the implementation is naive :-/ Summary: - similar to clip; - filters provide a way to get the output window (bounding box) given a set of 'filtered' objects; - filters allocate a temporary ARGB buffer, all objects are rendered there in order, then this buffer is filtered and the output is placed at the screen (outbuf). Maybe the implementation will be smart enough and filters should also return if the image should be ARGB or RGB (ie: rotate a jpeg) and if the output have holes and should be handled as transparent or not (rotate a jpeg = transparent area, blur a jpeg = opaque area). These buffers can be GL Framebuffer Objects... - filters should work based on the output window, this will avoid holes in the output for some filters (ie: rotation). Maybe it can be flexible enough to support the other way? Does it worth to have both? - not clear on how to go with smart objects api, needs evaluation. This is exactly what I don't like.. It's complex, slow, and I feel not really needed or warranted. Most of what people really want is fairly simple - transform an object and possibly mask it with an image or gadient (itself possibly transformed), possibly with some 'effects' filter applied (pointwise or spatial), and composite with the dst surface (image objs can also have a separate fill-transfom set on them much like grad objs now allow for fill rotations). This can be done easily and efficiently via separate transforms, masks, and a certain set of 'effects' filters (blur, cmods, etc), if need be.. and avoid complexities of modifiers of modifiers of modifiers of with no clear mechanism for optimization except happy buffer land. But if everyone feels that the generalized 'clip' mechanism is the way to go.. then fine, please do carry on. If _I_ would do it, I'd do it for usage with OpenGL or other hw-accelerated systems, so this would map easily to them and would be fast. That remains to be seen - ie. just how fast a good antialias pipeline would be. Not only that though, but also wether such an approach is warranted as a basis for all engines, and maps well to common use cases, and has no 'surprises'. It's tempting to have a single mechanism, a powerful one that generalizes... but it can also be unsuitable for some things. I'd see something like that more as built-in to an immediate mode pipeline, perhaps even via the 'evas imaging' route... I just don't see such a generic method as satisfactory or necessary for the kinds of uses that evas objects would be called upon in most real-time rendering. As I mentioned, I actually did most of this before and didn't like it - unwarranted complexity that was difficult to optimize for most common cases that I could foresee.. But who knows. However, as I said, I have no time to work on this ATM, so if you like to try an alternative approach, please do it. Keep it as a branch somewhere and share your results, someone may test it and see how well it works, maybe it would suffice and this would be integrated, everyone is happy :-) I've already tried both approaches, and others as well. There's nothing here that's new, though there's certainly more than one way to do anything. As to some 'branch' somewhere.. maybe it's best to wait and see how your approach works out and if that would suffice, integrate it as you say. :) - 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
