>>
>>>> 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
