>> 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 the same manner that's done with 'shading languages'.
b) Retain most of the legacy stuff that was there originally and support most
common kinds of uses/types.
c) Have some similarity with the use of image objects.
d) Make it work reasonably with things like edje.
e) Other more obscure reasons like premul vs. non-premul interpolation.
One could have done things differently -- for example one could have
separate kinds of gradient objects, one for each type of gradient that would
be chosen to be supported, and an api specific to that type.. eg. say one
obj = evas_object_linear_gradient_add(evas);
and then have
evas_object_linear_gradient_points_set(obj, x0, y0, x1, y1);
but you can get this with what's there now by doing the following:
linear_gradient_points_set_set(obj, x0, y0, x1, y1)
{
int dx, dy, fw, fh;
float angle;
dx = x1 - x0; dy = y1 - y0;
fw = abs(dx) + 1; fh = abs(dy) + 1;
angle = -(atan2(dx, dy) * 180.0) / M_PI;
evas_object_gradient_type_set(obj, "linear", NULL);
if (x0 > x1) { int t = x1; x1 = x0, x0 = t; }
if (y0 > y1) { int t = y1; y1 = y0, y0 = t; }
evas_object_gradient_fill_set(obj, x0, y0, fw, fh);
evas_object_gradient_angle_set(obj, angle);
}
and similarly you could have something like
obj = evas_object_radial_gradient_add(evas);
and then have
evas_object_radial_gradient_geometry_set(obj, cx0, cy0, radius);
but again you also can get this from what's there now.
Note that we haven't gone into 'how' gradients may be used in various
possible ways.. just how one might define them as semi-abstract objects.
Eventually, one'd like to be able to use both gradient and image objects as
'textures' for certain other objects - stroked/filled rectangles (with rounded
corners), and similarly for lines, polys, paths, ... maybe even text. One'd
also maybe want to use them as 'masks', and possibly via some immediate-mode
kinds of constructions.
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?
____________________________________________________________
Fabulous Spa Getaway!
Enter for your chance to WIN great beauty prizes everyday!
http://thirdpartyoffers.juno.com/TGL2141/fc/JKFkuJi7Urp3sU8J9cjZWE6ko2E5QS9ALYcjOJ7POo6Ej1HD1FEoH1/
-------------------------------------------------------------------------
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
