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 > 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 and next (if any) > stop > // positions in the gradient, and again does nothing if 'index' >= > current > // number of stops or index < 0. > > void evas_object_gradient_color_stop_remove(obj, int index); > // removes the color stop at that index, where again the index needs > to > // be valid or nothing is done. > > Before continuing, let me point to another big issue - namely, > whether > the "r,g,b,a" should be taken as premul color data and then also add > support > for a similar set of api funcs that deal with separate alpha_stops... > OR, > should one take these gradient stops as being given by non-premul > color data? > The latter is what just about all vgfx apis/specs support - for better > or worse. > If writing engines that are more directly able to use apis like > cairo > or other common vgfx ones is important, then I suggest going with > this... > If more flexibility is desired then go with separate premul-color & > alpha stops. > > The other api funcs are optional, so if minimality, and vgfx > apis/specs > comformance is desired, then get rid of: > > void evas_object_gradient_color_data_set(obj, .....); > void evas_object_gradient_alpha_data_set(obj, .....); > void evas_object_gradient_direction_set(obj, .....); > void evas_object_gradient_offset_set(obj, .....); > > > If no one has any comments on anything, I suggest getting rid of > everything > currently there for spectrum related funcs and only having the minimal > two: > > void evas_object_gradient_clear(obj); > void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); > > where the r,g,b,a is assumed to be non-premul. > > This would make things much more "standard" for this aspect (1) > of gradients. > > > > ____________________________________________________________ > Click to replace your roof - modern technology. > http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nHHOC0UtiY6omqA66sli6egaWYJBb1dCQiwoa71uLOGPhJe/ > > ------------------------------------------------------------------------- > 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 ------------------------------------------------------------------------- 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
