Re: [E-devel] [Evas] possible bug in gradient
On Wed, 09 Jul 2008 19:33:14 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: it's a matter of how high level you want the api. in fact your end api (the minimal one) is exactly what my original gradient api had.. just add a point a distance from another with a color - it's linear interpolation. clear it and re-fill it again when you want to change i. if you want different interpolation types (logarithmic, etc.) a higher level api can break this down int a series of linear interp points. the more points - the better the quality. the other option is to be able to define gradient interp point angles(like defining a spline curve...) but evas has nothing for that currently... so a simple linear point api means there is less to worry about... for now :) but i've never been into gradients. personally. so i am not the one to comment. i'm no expert nor do i have vested interests. so don't take my comments too seriously. So, if anyone has any comments, suggestions, issues.. *anything* with evas gradients -- now would be a good time to pipe in. :) I'd _love_ using gradients, in fact I would use them much more often, _if_ not everytime I start using them, it all feels like I'm operating a powerful machine that has 100s of controls and I don't understand anything. Perhaps this is an inherent problem from the gradient complexity, but I'd appreciate if we had some documentary material that outlines how to achieve which kind of results, which gradient type to use for what, how many stops for what effect etc. etc. Ok, let me try and give you a fairly simplified description of what gradients are basically about, and how evas tries to deal with this.. for better or worse. ... ... ...But to get back to the subject at hand here, and before going on to give more details on current evas gradients, let me ask you this: How would you answer the above two 'general' questions.. or rather, what would *you* like to see as an api that would make you want to use gradients more? Not much time to reflect on this? Well, that's understandable :) Let me go ahead and review the current set of gradient api funcs in evas, give some criticisms, and propose some changes I'd like to make to improve things there (and yes, they would break all gradient stuff). First, recall I mentioned the two parts involved in gradients: 1) Those aspects related to defining a 1-dim image (or spectrum as I sometimes call it). 2) Those aspects related to defining how to map the above to a 2-dim region - and this covers things like the gradient type, spread-mode, and such things. Ok, for (1) in evas we currently have the following (set) api funcs: void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta); void evas_object_gradient_alpha_stop_add(obj, a, int delta); void evas_object_gradient_color_data_set(obj, *data, len, has_alpha); void evas_object_gradient_alpha_data_set(obj, *data, len); void evas_object_gradient_direction_set(obj, *data, int direction); void evas_object_gradient_offset_set(obj, *data, float offset); and also, void evas_object_gradient_clear(obj); The 'clear' api func removes any stops or data that might have been set before. The 'offset' api func effectively moves the origin of the 1-dim image, this is something that as far as I know isn't supported by any vgfx api/spec (which is unfortunate since it can give very nice animation effects which are otherwise difficult to obtain for some gradient types, eg. radial ones). The 'direction' api func just reverses the start/end of the 1-dim, and though not directly supported by most vgfx apis/specs, it can be easily obtained - it's mostly a simple convenience function. The 'color_data' and 'alpha_data' api funcs are to allow for setting such a 1-dim image with premul and alpha-only data, rather than going thru any kind of procedural description. It's not supported by any vgfx api/spec that I know of, not directly anyway.. though you can certainly consider such data as an equi-distant set of stops and add it that way (modulo some gymnastics with premul data and alpha masks and such). The 'color_stop' and 'alpha_stop' api funcs evas' current procedural descriptions for defining the spectrum -- and these I have real issues with. Not only is this method of specifying stops not supported by any 'standard' vgfx api/spec, the use of the int delta as either some kind of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and very difficult to work with for gui editors and such. I propose getting rid of this legacy stuff (inhereted from the equally archaic Imlib2 method), and adopt a more standard method. In fact, let's start from scratch altogether here and let me propose a minimal set of
Re: [E-devel] [Evas] possible bug in gradient
Ok, to continue with my review and critique of evas gradients.. For the second (2) aspect of these, we have the following api (set) functions: Evas_Object *evas_object_gradient_add(Evas *e); void evas_object_gradient_type_set(obj, const char *type, const char *instance_params); void evas_object_gradient_fill_set(obj, Evas_Coord x, Evas_Coord y, Evas_Coord w, Evas_Coord h); void evas_object_gradient_fill_angle_set(obj, Evas_Angle angle); void evas_object_gradient_fill_spread_set(obj, int tile_mode); void evas_object_gradient_angle_set(obj, Evas_Angle angle); These were the result of *largely* wanting to extend what evas originally had with gradients to support such things as radial (and other) gradient types, 'spread' modes, and various fill geometries, and to do so with minimal changes in what was there to begin with, as simply as possible, and fix some early problems encountered with edje grads, and a couple of other minor reasons. The first api func just adds a generic gradient obj to the canvas - as was there from the start. The 'type' one allows for setting various types of gradients (linear, radial,...) and any special parameters they might support - it was the simplest way to 'add' types of gradients to what was there in evas. The 'fill' one is a generic means of specifying a fill geometry for the various types, analogous to what was used for images - it's good for many types of gradients though not always the most natural way to do so for any given type. The 'fill-angle' one is a means to rotate the gradient geometry around the fill origin - a very simplified way to add basic transform-like ability. The 'fill-spread' one allows for specifying the means to extend the way the gradient is rendered outside the fill region.. you have basic repeat/reflect/pad and some possibly others. It's used by most all vgfx apis/specs that deal with grads. Lastly, the 'angle' one is a means to specify an initial orientation for linear gradients - was there to begin with and is basically a high-level convenience func to get a kind of alignment 'fitted' to the fill region. The 'problem' with these, is basically that they are too restrictive in some ways, not easy to query the state of the vague 'params', and not very intuitive for some grad geometries/types.. nor are they very 'standard'. Here's a new api I'd like to propose, a fairly 'standard' one: First of all, remove the generic gradient type and have separate api funcs for each type that evas wants to support by default - any subsequent custom types that may be desired can be added as seen fit, or simply via 'object modules'... something which is needed anyway and not too difficult to add to evas, though edje/edc needs more thought and work to allow for such things. Let's say we want linear_gradients, radial_gradients, and possibly angular_gradients, rectangular_gradients, sinusoidal_gradients, and maybe such things like triangular ones or star-shaped ones or one that's like taking the distance to a line, or other kinds.. though all these can be left as 'modules'. We'd then have no more generic gradient type, and have instead: Evas_Object *evas_object_gradient_[type]_add(e); where 'type' is any of linear, radial, etc. as desired. However, all the api funcs related to specifying spectra on these would remain the same, as if these gradient types were derived from a generic base gradient type. Then, we'd specify a 'fill' geometry for each type, fitted to that type.. eg. for linear and radial gradients we'd have: void evas_object_gradient_linear_fill_set(obj, Evas_Coord x0, Evas_Coord y0, Evas_Coord x1, Evas_Coord y1); // set the linear grad geometry from point (x0,y0) to (x1,y1) void evas_object_gradient_radial_fill_set(obj, Evas_Coord x0, Evas_Coord y0, Evas_Coord rx, Evas_Coord ry); // set the radial grad geometry with center (x0,y0) and radii (rx,ry) // In both of these, one could use floats instead. and if more 'fill geometry' related params are needed or desired for the given type, then they would be additional.. eg, one could have one to set foci for radial gradients, or an inner_radius, or whatnot. We'd then keep the current generic 'spread' api func, but get rid of both the 'fill_angle' and 'angle' ones.. and instead add one to set a 'fill transform': void evas_object_gradient_fill_transform_set(obj, Evas_Transform *t); where though an 'Evas_Transform' defines a 3x3 matrix for general projective transformations, for the purposes of transforming such 'fill' geometries, we'd use only the affine part - this because only affine transforms are supported for such things by all the vgfx apis/specs. In all, for (2) one'd then have: Evas_Object *evas_object_gradient_[type]_add(e); void evas_object_gradient_[type]_fill_set(obj,
Re: [E-devel] [Evas] possible bug in gradient
Again, though not completely to my personal liking (and contradicting my original version), I'd like to propose changing the evas gradient 'spectrum' api to be of the form: evas_object_gradient_color_stop_insert(grad, r, g, b, a, float pos); where the 'r,g,b,a' part of the color-stop is assumed NON-PREMUL. Unless there's overwhelming resistance to this, or raster actually shows me that software 3D stuff he has from back when, I will change evas grad spectra to this form.. and hurt anyone who tries to stop it from being committed. :) And just to quadruple-state my reasons for proposing this: I would *prefer* to have (closer to the current version), evas_object_gradient_color_stop_insert(grad, r, r, b, a, float pos); evas_object_gradient_alpha_stop_insert(grad, a, float pos); where the rgba in the color-stop one are assumed premul, and I would also keep the 'data' ones, evas_object_gradient_color_data_set(grad, *data, len, has_alpha); evas_object_gradient_alpha_data_set(grad, *data, len); They're far more flexible and consistent with a premul compositing model.. BUT, the problem with these is that there's NO way to directly implement them (in general) with things like xrender, or cairo, or OpenVG, We'd have to do things in software most of the time and create implementation complications in general to get some direct support. It was a good experiment, and there are people who would like to see this kind of thing, but it's likely never going to happen with any of the standards or with most libs/apis one could use for engine backends.. :( Hence, better to conform, as this aspect is important. Of course this is as far as the premul vs non-premul stops deal. The other part of changing to inserting with a float pos rather than adding stops with some int delta/distance/whatnot.. is partly in order to also have more direct 'standard' support, but also to make it somewhat more intuitive. There is one other option here -- namely to accomodate *both* kinds of color-stops, premul and non-premul (with no mixing of the two - doing so would clear the gradient of the former different set of stops or data), so that one can keep both ways. If an engine backend supports only non-premul stops, then those are done directly, and one reverts to software for the premul ones. So, as a more 'positive' alternative, one may consider: // premul color-stops api, evas_object_gradient_color_stop_insert(grad, r, r, b, a, float pos); evas_object_gradient_alpha_stop_insert(grad, a, float pos); and also the 'data' ones (the color data premul of course) evas_object_gradient_color_data_set(grad, *data, len, has_alpha); evas_object_gradient_alpha_data_set(grad, *data, len); and also, // non-premul color-stops api, evas_object_gradient_color_np_stop_insert(grad, r, r, b, a, float pos); where of course the 'np' stands for non-premul r,g,b,a. Hotel pics, info and virtual tours. Click here to book a hotel online. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nLmLRYlJnF5QRabaPWTj3m9UzpmwX10g1vyCHFScPiHEBcc/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evas] possible bug in gradient
Let me continue with this evas gradients overview and with my 'critique' of its current state (largely due both to me and to legacy and other constraints), and to continue proposing *api-breaking* changes. Before doing so though, let me quickly point out something to Dave regarding his (really nice) work on adding grad support to edje-editor: Be careful with the issue of premul vs non-premul color spaces. Edje deals with non-premul color stops for gradients, whereas evas deals with premul color stops and separate alpha stops. You can get the former via the latter easily, but not the other way around. If you want to 'input' non-premul color stops, ie. (r,g,b,a, d) where the 'a' isn't restricted to satisfy a = r,g,b, like edje does, then in order to emulate this in evas (currently), you must do: evas_object_gradient_color_stop_add(grad, r, g, b, 255, d); evas_object_gradient_alpha_stop_add(grad, a, d); this is what edje does internally - it's NOT the same thing as: evas_object_gradient_color_stop_add(grad, r, g, b, a, d); in fact, this latter will give you some very unexpected results, in general, if the r,g,b,a are indeed non-premul. :) It's a shame that all gfx apis/specs that deal with gradients use only the legacy non-premul approach :( But it doesn't appear that this is *ever* going to change with any of the standards, or any libs that want to support such standards and little else... Hence my suggestion that evas do likewise. It would be the simplest way to be able to have direct support for grads via most engine 'backends' that are around. Again, though not completely to my personal liking (and contradicting my original version), I'd like to propose changing the evas gradient 'spectrum' api to be of the form: evas_object_gradient_color_stop_insert(grad, r, g, b, a, float pos); where the 'r,g,b,a' part of the color-stop is assumed NON-PREMUL. Unless there's overwhelming resistance to this, or raster actually shows me that software 3D stuff he has from back when, I will change evas grad spectra to this form.. and hurt anyone who tries to stop it from being committed. :) I'll also go over the other half of the evas grad api (ie. related to type of grad, fill geometries, spread modes, and such stuff) a bit later, but any comments on this part from developers, designers, grandmothers, ... would be welcomed. Explore all of Europe's beauty! Click now for great vacation packages! http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nKHLljrNsrAODiA6pFsQs8I4BnXKWo8Vt4B1zhhjjD1aW96/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evas] possible bug in gradient
I wrote: So, if anyone has any comments, suggestions, issues.. *anything* with evas gradients -- now would be a good time to pipe in. :) I'd _love_ using gradients, in fact I would use them much more often, _if_ not everytime I start using them, it all feels like I'm operating a powerful machine that has 100s of controls and I don't understand anything. Perhaps this is an inherent problem from the gradient complexity, but I'd appreciate if we had some documentary material that outlines how to achieve which kind of results, which gradient type to use for what, how many stops for what effect etc. etc. Ok, let me try and give you a fairly simplified description of what gradients are basically about, and how evas tries to deal with this.. for better or worse. ... ... ... But to get back to the subject at hand here, and before going on to give more details on current evas gradients, let me ask you this: How would you answer the above two 'general' questions.. or rather, what would *you* like to see as an api that would make you want to use gradients more? Not much time to reflect on this? Well, that's understandable :) Let me go ahead and review the current set of gradient api funcs in evas, give some criticisms, and propose some changes I'd like to make to improve things there (and yes, they would break all gradient stuff). First, recall I mentioned the two parts involved in gradients: 1) Those aspects related to defining a 1-dim image (or spectrum as I sometimes call it). 2) Those aspects related to defining how to map the above to a 2-dim region - and this covers things like the gradient type, spread-mode, and such things. Ok, for (1) in evas we currently have the following (set) api funcs: void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta); void evas_object_gradient_alpha_stop_add(obj, a, int delta); void evas_object_gradient_color_data_set(obj, *data, len, has_alpha); void evas_object_gradient_alpha_data_set(obj, *data, len); void evas_object_gradient_direction_set(obj, *data, int direction); void evas_object_gradient_offset_set(obj, *data, float offset); and also, void evas_object_gradient_clear(obj); The 'clear' api func removes any stops or data that might have been set before. The 'offset' api func effectively moves the origin of the 1-dim image, this is something that as far as I know isn't supported by any vgfx api/spec (which is unfortunate since it can give very nice animation effects which are otherwise difficult to obtain for some gradient types, eg. radial ones). The 'direction' api func just reverses the start/end of the 1-dim, and though not directly supported by most vgfx apis/specs, it can be easily obtained - it's mostly a simple convenience function. The 'color_data' and 'alpha_data' api funcs are to allow for setting such a 1-dim image with premul and alpha-only data, rather than going thru any kind of procedural description. It's not supported by any vgfx api/spec that I know of, not directly anyway.. though you can certainly consider such data as an equi-distant set of stops and add it that way (modulo some gymnastics with premul data and alpha masks and such). The 'color_stop' and 'alpha_stop' api funcs evas' current procedural descriptions for defining the spectrum -- and these I have real issues with. Not only is this method of specifying stops not supported by any 'standard' vgfx api/spec, the use of the int delta as either some kind of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and very difficult to work with for gui editors and such. I propose getting rid of this legacy stuff (inhereted from the equally archaic Imlib2 method), and adopt a more standard method. In fact, let's start from scratch altogether here and let me propose a minimal set of grdient-spectrum related api functions that more closely matches what's given by most vgfx apis/specs: void evas_object_gradient_clear(obj); // keep this one void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); // where 'pos' is clamped to be in [0,1]. Any previous stop at same pos // will be overwritten. Must insert one stop at pos 0 and one at pos 1 // to get a valid gradient spectrum. This and matches what most use. One could then possibly add the following funcs to make it easier/more-intuitive to input, query, and manipulate such gradient stops: void evas_object_gradient_color_stop_get(obj, int index, *r,*g,*b,*a,*pos); // get the value of the stop at 'index', where these are ordered from 0 to // (number_of_stops - 1) according to increasing position. If 'index' is = // the current number of stops, or index 0, this does nothing. void evas_object_gradient_color_stop_set(obj, int index, r,g,b,a,pos); // modifies the r,g,b,a,pos values of the stop at the given index, // where 'pos' is clamped to lie between the prev
Re: [E-devel] [Evas] possible bug in gradient
forget my previous mail; it was a problem with my mail client sorry Vincent - 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] possible bug in gradient
I had worked on the gradient spectra manager in edje_editor, it is ready now, you will see my work in cvs soon. I have done a cool spectra editor and yes, the 'delta' param is a hell! I agree with you also with the rest of the api :) ...but updating all the code that use gradient could be paintfull... Dave - Jose Gonzalez [EMAIL PROTECTED] ha scritto: I wrote: So, if anyone has any comments, suggestions, issues.. *anything* with evas gradients -- now would be a good time to pipe in. :) I'd _love_ using gradients, in fact I would use them much more often, _if_ not everytime I start using them, it all feels like I'm operating a powerful machine that has 100s of controls and I don't understand anything. Perhaps this is an inherent problem from the gradient complexity, but I'd appreciate if we had some documentary material that outlines how to achieve which kind of results, which gradient type to use for what, how many stops for what effect etc. etc. Ok, let me try and give you a fairly simplified description of what gradients are basically about, and how evas tries to deal with this.. for better or worse. ... ... ... But to get back to the subject at hand here, and before going on to give more details on current evas gradients, let me ask you this: How would you answer the above two 'general' questions.. or rather, what would *you* like to see as an api that would make you want to use gradients more? Not much time to reflect on this? Well, that's understandable :) Let me go ahead and review the current set of gradient api funcs in evas, give some criticisms, and propose some changes I'd like to make to improve things there (and yes, they would break all gradient stuff). First, recall I mentioned the two parts involved in gradients: 1) Those aspects related to defining a 1-dim image (or spectrum as I sometimes call it). 2) Those aspects related to defining how to map the above to a 2-dim region - and this covers things like the gradient type, spread-mode, and such things. Ok, for (1) in evas we currently have the following (set) api funcs: void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta); void evas_object_gradient_alpha_stop_add(obj, a, int delta); void evas_object_gradient_color_data_set(obj, *data, len, has_alpha); void evas_object_gradient_alpha_data_set(obj, *data, len); void evas_object_gradient_direction_set(obj, *data, int direction); void evas_object_gradient_offset_set(obj, *data, float offset); and also, void evas_object_gradient_clear(obj); The 'clear' api func removes any stops or data that might have been set before. The 'offset' api func effectively moves the origin of the 1-dim image, this is something that as far as I know isn't supported by any vgfx api/spec (which is unfortunate since it can give very nice animation effects which are otherwise difficult to obtain for some gradient types, eg. radial ones). The 'direction' api func just reverses the start/end of the 1-dim, and though not directly supported by most vgfx apis/specs, it can be easily obtained - it's mostly a simple convenience function. The 'color_data' and 'alpha_data' api funcs are to allow for setting such a 1-dim image with premul and alpha-only data, rather than going thru any kind of procedural description. It's not supported by any vgfx api/spec that I know of, not directly anyway.. though you can certainly consider such data as an equi-distant set of stops and add it that way (modulo some gymnastics with premul data and alpha masks and such). The 'color_stop' and 'alpha_stop' api funcs evas' current procedural descriptions for defining the spectrum -- and these I have real issues with. Not only is this method of specifying stops not supported by any 'standard' vgfx api/spec, the use of the int delta as either some kind of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and very difficult to work with for gui editors and such. I propose getting rid of this legacy stuff (inhereted from the equally archaic Imlib2 method), and adopt a more standard method. In fact, let's start from scratch altogether here and let me propose a minimal set of grdient-spectrum related api functions that more closely matches what's given by most vgfx apis/specs: void evas_object_gradient_clear(obj); // keep this one void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); // where 'pos' is clamped to be in [0,1]. Any previous stop at same pos // will be overwritten. Must insert one stop at pos 0 and one at pos 1 // to get a valid gradient spectrum. This and matches what most use. One could then possibly add the following funcs to make it easier/more-intuitive to input, query, and manipulate such
Re: [E-devel] [Evas] possible bug in gradient
So, if anyone has any comments, suggestions, issues.. *anything* with evas gradients -- now would be a good time to pipe in. :) I'd _love_ using gradients, in fact I would use them much more often, _if_ not everytime I start using them, it all feels like I'm operating a powerful machine that has 100s of controls and I don't understand anything. Perhaps this is an inherent problem from the gradient complexity, but I'd appreciate if we had some documentary material that outlines how to achieve which kind of results, which gradient type to use for what, how many stops for what effect etc. etc. Ok, let me try and give you a fairly simplified description of what gradients are basically about, and how evas tries to deal with this.. for better or worse. ... ... ...But to get back to the subject at hand here, and before going on to give more details on current evas gradients, let me ask you this: How would you answer the above two 'general' questions.. or rather, what would *you* like to see as an api that would make you want to use gradients more? Not much time to reflect on this? Well, that's understandable :) Let me go ahead and review the current set of gradient api funcs in evas, give some criticisms, and propose some changes I'd like to make to improve things there (and yes, they would break all gradient stuff). First, recall I mentioned the two parts involved in gradients: 1) Those aspects related to defining a 1-dim image (or spectrum as I sometimes call it). 2) Those aspects related to defining how to map the above to a 2-dim region - and this covers things like the gradient type, spread-mode, and such things. Ok, for (1) in evas we currently have the following (set) api funcs: void evas_object_gradient_color_stop_add(obj, r,g,b,a, int delta); void evas_object_gradient_alpha_stop_add(obj, a, int delta); void evas_object_gradient_color_data_set(obj, *data, len, has_alpha); void evas_object_gradient_alpha_data_set(obj, *data, len); void evas_object_gradient_direction_set(obj, *data, int direction); void evas_object_gradient_offset_set(obj, *data, float offset); and also, void evas_object_gradient_clear(obj); The 'clear' api func removes any stops or data that might have been set before. The 'offset' api func effectively moves the origin of the 1-dim image, this is something that as far as I know isn't supported by any vgfx api/spec (which is unfortunate since it can give very nice animation effects which are otherwise difficult to obtain for some gradient types, eg. radial ones). The 'direction' api func just reverses the start/end of the 1-dim, and though not directly supported by most vgfx apis/specs, it can be easily obtained - it's mostly a simple convenience function. The 'color_data' and 'alpha_data' api funcs are to allow for setting such a 1-dim image with premul and alpha-only data, rather than going thru any kind of procedural description. It's not supported by any vgfx api/spec that I know of, not directly anyway.. though you can certainly consider such data as an equi-distant set of stops and add it that way (modulo some gymnastics with premul data and alpha masks and such). The 'color_stop' and 'alpha_stop' api funcs evas' current procedural descriptions for defining the spectrum -- and these I have real issues with. Not only is this method of specifying stops not supported by any 'standard' vgfx api/spec, the use of the int delta as either some kind of 'weight' or maybe 'distance to a next' is somewhat un-intuitive and very difficult to work with for gui editors and such. I propose getting rid of this legacy stuff (inhereted from the equally archaic Imlib2 method), and adopt a more standard method. In fact, let's start from scratch altogether here and let me propose a minimal set of grdient-spectrum related api functions that more closely matches what's given by most vgfx apis/specs: void evas_object_gradient_clear(obj); // keep this one void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); // where 'pos' is clamped to be in [0,1]. Any previous stop at same pos // will be overwritten. Must insert one stop at pos 0 and one at pos 1 // to get a valid gradient spectrum. This and matches what most use. One could then possibly add the following funcs to make it easier/more-intuitive to input, query, and manipulate such gradient stops: void evas_object_gradient_color_stop_get(obj, int index, *r,*g,*b,*a,*pos); // get the value of the stop at 'index', where these are ordered from 0 to // (number_of_stops - 1) according to increasing position. If 'index' is = // the current number of stops, or index 0, this does nothing. void evas_object_gradient_color_stop_set(obj, int index, r,g,b,a,pos); // modifies the r,g,b,a,pos values of the stop at
Re: [E-devel] [Evas] possible bug in gradient
While everyones talking about gradients, Ive a request... Id like to
be able to create a gradient that goes from sollid white to alpha then
clip an image to it so that the image fades away. Something like
this...
spectra {
spectrum {
name: sp2;
color: 255 255 255 255 1;
color: 0 0 0 0 1;
}
}
collections {
group {
name: Test;
parts {
part {
name: base;
type: GRADIENT;
mouse_events: 0;
description {
state:default 0.0;
gradient.spectrum: sp2;
fill.spread: 1;
}
}
part {
name: chinaman;
mouse_events: 0;
type: IMAGE;
clip_to: base;
description {
state:default 0.0;
image.image: ChinaManBeard.jpg COMP;
image.normal: ChinaManBeard.jpg;
}
}
}
}
}
In this example I was trying to get this image to fade like the
gradient does. If you clip the image to a normal RECT then fade the
clip box it will fade the image too.
Would be nice, but not essential. Im guessing the mechanics behind it
are alot more complex than I comprehend...
Toma
-
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] possible bug in gradient
Toma wrote:
While everyones talking about gradients, Ive a request... Id like to
be able to create a gradient that goes from sollid white to alpha then
clip an image to it so that the image fades away. Something like
this...
spectra {
spectrum {
name: sp2;
color: 255 255 255 255 1;
color: 0 0 0 0 1;
}
}
collections {
group {
name: Test;
parts {
part {
name: base;
type: GRADIENT;
mouse_events: 0;
description {
state:default 0.0;
gradient.spectrum: sp2;
fill.spread: 1;
}
}
part {
name: chinaman;
mouse_events: 0;
type: IMAGE;
clip_to: base;
description {
state:default 0.0;
image.image: ChinaManBeard.jpg COMP;
image.normal: ChinaManBeard.jpg;
}
}
}
}
}
In this example I was trying to get this image to fade like the
gradient does. If you clip the image to a normal RECT then fade the
clip box it will fade the image too.
Would be nice, but not essential. Im guessing the mechanics behind it
are alot more complex than I comprehend...
Toma
This is something very useful and indeed I would like to add this
ability to evas. I would add this as the ability to mask any object by
either an image or gradient object.
I *don't* want to add it via the current clipping mechanism. Why?
Because I implemented just that sometime back and ran into several semantic
and practical 'issues' that I truly don't like. I'd leave clipping as is -
clip to rectangles and ignore any transforms, corners, whatnot these objs
might have.. ie. a pure rectangular display region clipping mechanism.
The separate mask approach allows for a simpler, easier to optimize,
directly supported by most engines, and gives a powerful method since the
mask objects (images or gradients) can be transformed and/or filtered.
With it, you can get all the nifty 'new' reflection stuff that apple's
made famous recently, and a lot more such masking effects (eg. mask with
a buffer evas, indirectly, by masking with the associated image).
NB: This is somewhat similar to (though not exactly the same as)
fill and/or stroke texturing of vgfx objs with image or grad objects.
Click to become a designer and quit your boring job.
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l7MABetj9UMyNeM7OIM8bHr74HKPatHWDUwfP2rv45TmoDt/
-
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] possible bug in gradient
So, if anyone has any comments, suggestions, issues.. *anything* with evas gradients -- now would be a good time to pipe in. :) I'd _love_ using gradients, in fact I would use them much more often, _if_ not everytime I start using them, it all feels like I'm operating a powerful machine that has 100s of controls and I don't understand anything. Perhaps this is an inherent problem from the gradient complexity, but I'd appreciate if we had some documentary material that outlines how to achieve which kind of results, which gradient type to use for what, how many stops for what effect etc. etc. Ok, let me try and give you a fairly simplified description of what gradients are basically about, and how evas tries to deal with this.. for better or worse. There are really two independent aspects to gradients: 1. A 1-dim image of possibly variable length. 2. A means of mapping this image onto a planar region to create a 2-dim image, and this is what's often wrapped under the term of the 'type' of gradient, as well as other things such as the 'repeat-mode' and other stuff. For (1), there are multitudes of ways one can use to define such a 1-dim image, and everyone has their own idea of what a simple, or natural, or powerful, or whatever favorite way. Often, this is given in a 'procedural' way and involves specifying some set of colors strung out along some abstract line element. One then interpolates 'in-between' the given colors to obtain the full 1-dim image of colors. One common method for such a description is eg. what's specified in the svg spec, namely one gives a sequence of colors and positions on the [0,1] interval. Imlib2 allows one to specify a sequence of colors and some abstract 'distance' to the next color. Evas has something similar but the distance is more like a 'weight' for that color. The Gimp allows one to define some sequence of colors together with the position of the 'half-way' color (or some such, I can't recall anymore), and allows for various kinds of interpolation in-between (linear and some others). There are others as well. So you see, there are any number of ways to 'specify' what the 1-dim image is to be, abstractly or not, and in evas I went ahead and just allowed you to give a 1-dim image as well, in case you don't want to bother with some procedural representations. In general, we may ask: What should be the kinds of such descriptive means that evas should support for defining the 1-dim image (or 'spectrum' as I've sometimes called it) that one needs for gradients? Now, for (2), there are again any number of means by which one can map a 1-dim image onto a planar region, but a common one used is to give a function float f(float x, float y) which is used roughly as follows: for input (x,y) let r = f(x,y), and somehow pick a color on the 1-dim image that corresponds to this r. For example, a linear gradient corresponds to any number of linear functions of x, y, eg. anything of the form f(x,y) = a*x + b*y; will define a 'linear gradient'. Similarly, a radial gradient can be defined by the function f(x,y) = sqrt(x*x + y*y); or similar quadratic functions of x,y. An angular gradient can be defined by atan2(y,x); a rectangular gradient by the func f(x,y) = max(|x|,|y|); an 8-pointed star gradient can be defined by f(x,y) = (1 + 1/(4-2*sqrt(2)))/2 * min((1 / sqrt(2))*(|x|+|y|), max (|x|,|y|)); a sinusoidal gradient by f(x,y) = y - sin(a*x); and the list is of course endless. The thing about many of these functions is that the values r = f(x,y) can vary arbitrarily, and one wants the gradient to be somehow 'fitted' to a given planar region it can minimally fill (thus effectively determining the range of the 1-dim image), hence one needs to map those values of 'r' to be within the range of the 1-dim image. This is what gives rise to the various repeat (or extend, or spread) modes.. things like repeat/reflect/pad/... Given this infinite flexibility as to gradient types and the various kinds of 'geometries' that those implicitly define, people often tend to pick one or two common ones and define separate apis for the particulars of those geometries. For example, for linear gradients people often expose something like the linear gradient from point p0 to point p1, or the radial gradient centered at point c and of radius r, and similar such specialized things - one set of api funcs for each gradient 'type'. In general, we may again ask: What should be the descriptive methods that evas should support for defining the 'types' of geometric mappings that one wants for gradients? What's in evas right now (and also part of the latest proposal on having another method of defining gradient spectra) is one attempt to answer these two questions subject to certain constraints: a) Retain some flexibility - eg. one can define new gradient types easily, and pass parameters much in
Re: [E-devel] [Evas] possible bug in gradient
Vincent wrote:
Hey,
before putting that in bugzilla, here is what I obtain with the following
code:
[code]
o = evas_object_gradient_add (evas);
evas_object_gradient_fill_angle_set(o, 90);
evas_object_gradient_fill_spread_set(o, 1);
evas_object_gradient_fill_set(o, 0, 0, w, h);
evas_object_gradient_clear(o);
evas_object_gradient_color_stop_add(o,
255,
0,
0,
255,
2);
evas_object_gradient_color_stop_add(o,
0,
255,
0,
255,
2);
evas_object_resize(o, w, h);
evas_object_image_fill_set(o, 0, 0, w, h);
evas_object_move (o, 10, 10);
evas_object_show (o);
[/code]
the result:
http://www.maths.univ-evry.fr/pages_perso/vtorri/files/gradient_bug.png
that is, there is a red vertical line at the left of the gradient, while
that line should be at the right (imo)
is it a bug ?
Vincent
Since we've been dragged back into gradient land recently, I went ahead
and 'fixed' this 'bug' and a few other minor such grad things. But before
finishing with this, I thought I'd mention an aspect of grads that people might
feel needs improving - namely, the issue of how to specify 'stops'.
A common, or 'standard', way to do this is by defining a color (or alpha)
stop to be a color (or alpha) plus a 'position' in [0,1], not like the current
description of stops. This might be a better method for defining gradient stops
in both a visually intuitive sense, and for creating gui widgets to
interactively
create grads/stops.
Now, one could replace evas' current method with this, or one could extend
evas to support this by adding an api func of the form:
void evas_object_gradient_color_stops_set(obj, Evas_List *stops);
where here 'stops' would be a list of Evas_Gradient_Color_Stop defined as
something
of the form { int r,g,b,a; float pos; } where pos is constrained to lie in
[0,1].
Similarly, one could have a 'get' func to return the list of previously
set such stops. The semantics would be that no copying is done in either set/get
so if one changes the values of some set of stops then one'd need to re-set them
again or one may not trigger an update (and btw, this also holds for the current
'data' set method).
There's a further option here with this - namely, one could take the
r,g,b,a
in the color-stop def to be non-premul, or keep as premul and also have separate
alpha-stops as is now done, ie. also have an Evas_Gradient_Alpha_Stop of the
form
{int a; float pos;} and set/get such a list of alpha stops.
So, if anyone has any comments, suggestions, issues.. *anything* with evas
gradients -- now would be a good time to pipe in. :)
Click here for great computer networking solutions!
http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3oHgMRKoGF8NN0xr9D572Uk2zb0l4dgt7e5fHRu1AuxxDgFh/
-
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
___
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evas] possible bug in gradient
[...] So, if anyone has any comments, suggestions, issues.. *anything* with evas gradients -- now would be a good time to pipe in. :) I'd _love_ using gradients, in fact I would use them much more often, _if_ not everytime I start using them, it all feels like I'm operating a powerful machine that has 100s of controls and I don't understand anything. Perhaps this is an inherent problem from the gradient complexity, but I'd appreciate if we had some documentary material that outlines how to achieve which kind of results, which gradient type to use for what, how many stops for what effect etc. etc. -- :M: - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evas] possible bug in gradient
Michael 'Mickey' Lauer wrote: [...] So, if anyone has any comments, suggestions, issues.. *anything* with evas gradients -- now would be a good time to pipe in. :) I'd _love_ using gradients, in fact I would use them much more often, _if_ not everytime I start using them, it all feels like I'm operating a powerful machine that has 100s of controls and I don't understand anything. Well, I kind of feel the same way about everything really. I'd say that the role of a gfx lib like evas is to provide a good amount of gfx flexibility without sacrificing speed or quality, and to do so via a reasonable api. In the end though, I think there's really no better way to deal with gfx stuff than via higher-level ibs/apis that simplify and narrow things down.. and ultimately, one really needs a good gfx gui-designer. Perhaps this is an inherent problem from the gradient complexity, but I'd appreciate if we had some documentary material that outlines how to achieve which kind of results, which gradient type to use for what, how many stops for what effect etc. etc. That would be useful, sure. There's really not much to 'gradients' themselves really, and I'll try to quickly go over some basic aspects a bit later, but as far as to how/when/why to use them... that's a bit nore open-ended and really brings us back to the above remarks about the need for gui tools and some experience with gfx design - and a bit more from evas than it can currently use gradients for. Click for information on the top Adult Education programs. Advance your career. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nNbXVhW5GIOV27WPtuh1WWK2e9FFXzRNTc3fL776n0nqfB9/ - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] [Evas] possible bug in gradient
Vincent wrote: before putting that in bugzilla, here is what I obtain with the following code: [code] o = evas_object_gradient_add (evas); evas_object_gradient_fill_angle_set(o, 90); evas_object_gradient_fill_spread_set(o, 1); evas_object_gradient_fill_set(o, 0, 0, w, h); evas_object_gradient_clear(o); evas_object_gradient_color_stop_add(o, 255, 0, 0, 255, 2); evas_object_gradient_color_stop_add(o, 0, 255, 0, 255, 2); evas_object_resize(o, w, h); evas_object_image_fill_set(o, 0, 0, w, h); How did that last line sneak its way in there. :) evas_object_move (o, 10, 10); evas_object_show (o); [/code] the result: http://www.maths.univ-evry.fr/pages_perso/vtorri/files/ gradient_bug.png that is, there is a red vertical line at the left of the gradient, while that line should be at the right (imo) is it a bug ? I would say it is a bug. If you have a chance to look into it, please do so Vincent. I probably won't be able to look at it for several days at least. jose. _ Click here for free information on nursing degrees, up to $150/hour http://thirdpartyoffers.juno.com/TGL2121/fc/Ioyw6i3nEnkqsCC5gFaXv4Ikwr77eXJ1Awq2LPpIvUf2DraNworXcs/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
