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

Re: [E-devel] Edje grad objs

> I committed a large chunk of the code for edje grads last night.
> I added angle and spread to the fill block, and reused the rest
> of fill (origin, size) for the grad fill. Angle will be interpolated
> during transitions, as will fill. The other params (spectrum, and
> spread for now) flip at the halfway point.

	It's great work man.. more than I ever imagined would be done
for months to come.
	I'm still not sure just what kinds of transitions edje deals
in.. so whatever you have, if you've found that it works as you wish,
then that would likely be best :)

> I also realized while doing it that I misunderstood how color stops
> were defined. I thought the 'distance' parameter was a distance
> 'from the previous stop'. Instead its more of a weight on a colors,
> defining the relative fraction of the spectra to be close to that
> color. I guess I need to dig into evas to see how this is actually
> implemented...

	Yeah :) The semantics you had in mind are the result of the
'color_add' api func using the term "distance"... though one could
also have interpreted it to mean distance to the next, rather than
the prev color. The docs mention instead some sort of weighting
	The implementation actually used to follow the dist-to-next
interpretation, or was it the dist-to-prev.. can't recall now.
	I changed it to follow something resembling the 'weighted'
interpretation of the docs :)
	This is done in a simple but qualitatively reasonable way
so as to conform with the docs' semantics: for each adjacent pair
of (c0,d0), (c1,d1) I add another one in between these two of the
form ((c0+c1)/2, d1), and the d's are taken as distance-to-next.
	Since the resuts are still linear w.r.t. the inputs (linear
enough anyhow), what you were planning to do to manually interpolate
color-stops in order to interpolate spectra, would've stii worked
fine. But again, if you're thinking about two different grad objs
then using the fade in/out method would be simpler.

	Everybody has their own idea of what a 'good' description
for gradient spectra should be :)
	The gimp's "ggr" format describes these as a sequence of
pairs of colors together with start and end positions for these
in [0,1], with the end of a prev pair being the start of the next,
and with a position for where the average color of each pair should
lie... It also allows for interpolations that aren't linear, eg.
sinusoidal, along an arc, and whatnot.
	The svg spec uses a sequence of colors plus positions in
	Other descriptions are possible, eg. something like the
avove but also specifying a 'control' color for doing quadratic
	One could even take the description to be given as the
definition of a spectrum function [0,1] --> ColorSpace via the
use of some programing language syntax.

	Again, everybody has a favorite 'really-good' description :)

> There are still a few small things to be done:
>  * the spectra{} block should be allowed inside other blocks (so you
>   can have it in an included file without worrying about where exactly
>   its included). edje_cc_handlers.c -- see the /* DUP */ lines for
>   examples.
> * need to check on 'recalc' that the spectrum has actually changed
>   before rebuilding the gradient's colors
> * anything else?

	I'll try and take a look a bit later and let you know if I
have anything meaningful to say :)

	Again, damn nice work Brian :)