[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [E-devel] Edje grad objs

On Mon, Jul 31, 2006 at 03:31:55PM +0000, jose_ogp@juno.com wrote:

(snipped for brevity)
> 	First, I would put the 'angle' and 'spread' properties
> under the general 'fill' tag. This is because that's really where
> they belong logically (describes various aspects of the way the
> filling of the object region is done), and also because image
> objects are going to get these very same properties as well
> (ie. image objects will get an angle and spread mode).

Easy enough to do.

How about 

spectrums {
  spectrum {
    name: "white_to_black";
    color: 255 255 255 255 0;
    color: 0 0 0 255 1;

(later we can have spectrum: "foo.ext"; for loading 'external' spectrum
definitions also)

I'm not sure I quite understand the definition of 'spread'. If set to 1,
you get a 'circular' domain (0..1,0..1,0..1...) and if set to 0 you get
a mirrored domain (0..1..0..1..0..1...). So, why is this called
'spread'? For images I assume this param would reflect the image over
each tile boundary?

Also, fill currently (at least with linear grads) is applied before
rotation. So, if you want a horizontal grad that fills the width of your
part, the fill would need to be (fillw, fillh) = (h, w). A bit odd from
a users perspective. How does/should this work for arbitrary angles?

> 	Given all this, the grad obj description would then follow
> the same pattern as img objs, ie. the gradient tag would then give
> reference to a spectrum source
> gradient {
>    normal: "spectrum_source";
> }

sounds good. what other fields would go inside the gradient block?
('type' (radial / linear / sinusoidal / etc ?)

> 	However, if you want 'transitions' that are actually able
> to interpolate between two grad descriptions, then there are a
> couple of issues to deal with:
> 	1. The grad 'type' must be the same (ie. both start and
> end grads must be linear, or radial, etc. One could do transitions
> between different geometries but it would have to be supported
> in evas itself).
> 	2. The 'spread' mode must also be the same, since this
> is a discrete set of states.
> 	Now we come to what you are considering: How to interpolate
> between two grad descriptions.
> 	Well, I would start about not thinking in terms of sets of
> color-stops and instead think in terms of the spectrums..
> 	If you have two spectrums s0,s1:[0,1]-->ColorSpace,
> it's easy to see what iterpolating between s0 and s1 means.
> For t in [0,1], we have a new spectrum s[t] defined by:
> 	s[t] = (1-t)*s0 + t*s1;
> ie. this means that for any f in [0,1], the value of s[t], at f,
> is given by
> 	s[t](f) = (1-t)*s0(f) + t*s1(f);

yes, this is what i was planning. for gradients 'inlined' and described
as a set of color stops, i can think of how to do it:

for each of the two gradients, g0 and g1, find the length (sum of
'distances' of all stops), and then convert stops to a coord between 0
and 1.

e.g. the following grad:

d color  (d is distance from previous stop)
0 blue
1 red
2 green
1 white

would have a length of 4 and the follow coordinate descriptiong

x color
0   blue
.25 red
.75 green
1   white

we do this for both grads, then find the union of the set of x coords,
interpolate the missing color values for each grad (e.g. find g0[x] for
x's that g1 defines but g0 doesn't).

now we have two gradients with the same # of stops at the same
distances, so we can just blend the values of g0 and g1 at each stop (by
how far along the transition we are) and we have our 'current' gradient.

for spectra given as pixel arrays, we'd just need to smoothly scale the smaller
to the size of the larger and blend them as above. (in essence though,
such spectra are defined as equidistant stops of the pixel colors,
right? so, we could just use the above algorithm...

> 	It's then a matter of converting this "abstract" version
> to what is needed in practice..
> 	However, doing this would require support for it in evas..
> Otherwise it would be somewhat difficult (if the spectra are
> inlined but have differing num of stops or distances as has been
> mentioned), or very difficult (if the spectra are defined via png
> or ggr files).
> 	I hadn't really thought about doing this though...
> But it's certainly something worth considering, and possibly
> for image objs as well.

for images, you can accomplish this by fading one out as the other fades