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 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. > > > > I negelected to directly give the next, > not-quite-so-standard-but-more-flexible, minimal alternative.. namely, keep > colors as premul and have color and alpha stops: > > void evas_object_gradient_clear(obj); > void evas_object_gradient_color_stop_insert(obj, r,g,b,a, float pos); > void evas_object_gradient_alpha_stop_insert(obj, a, float pos); > > and possibly then also keep the current color/alpha data set ones for even > greater flexibility if desired: > > void evas_object_gradient_color_data_set(obj, .....); > void evas_object_gradient_alpha_data_set(obj, .....); > > > ____________________________________________________________ > Fabulous Spa Getaway! > Enter for your chance to WIN great beauty prizes everyday! > http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7UrpfIisWJuFAa5Blk8IJUvnmOcuUdwidma0Bhxaf49tP7K/ > > ------------------------------------------------------------------------- > 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 > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [EMAIL PROTECTED] ------------------------------------------------------------------------- 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=100&url=/ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
