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
