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

Re: [E-devel] Edje grad objs

On Tue, Aug 01, 2006 at 06:46:03PM +0000, jose_ogp@juno.com wrote:

"ok" to everything snipped :)

> 	I would make the geometric 'type' its own block tag though
> (you could also call it 'geometry' instead of 'type' if you like),
> of the form say,
> type {
>    name: "type_name";
>    params: "whatever";
> }

to keep things from getting too deep, how abouting

  part {
    type: GRADIENT;
    description {
      gradient {
        type: "type_name";
        params: "param_name";
        spectrum: "spectrum name";
      fill {
        angle: 90;
        spread: 1; // will this take 2 params for images (x and y)?

also maybe the spectra definitions should be

spectra {
  spectrum {
    name: "foo";
    color: ...
  spectrum: "file.ext";

instead of gradients { gradient { name: ... } }
(to be a little more rigorous with our language)

> > 
> > 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...
> > 
> > 
> 	Well, that's exactly right.. However, I'm not sure edje
> should be the place to do it... But, see below.
> > > 
> > > 	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 in.
> > 
> 	That could have some limitations for rendering ops that aren't
> 'additive', but that's ok.
> 	Well, that would seem to be your solution right there -- 
> that's how you should do it in edje for grads as well.  :)

yeah. i actually started to mentioned that in the last email, and then
decided against it for some reason. doing two grad parts that fade in / out *should*
look the same as manually recalculating stops, and manually blending.

i guess it comes down to how we want the edc 'API' to be.

it would be _nice_ to support a single gradient part that has two states
with different spectra that transition. but this has the limitations
discussed (mostly that the gradient type must be the same). so,
definitely less work to just do

p3.spectrum = (pos > 0.5) ? p2.spectrum : p1.spectrum;

(e.g. hard switch of spectrum when the transition hits its 'half-way'

and require two parts for blending spectra. But, not as nice for edje

As for images, we have also have 'tween' transitions (frame based
animation), so fading between states isn't supported.

For now, i'll leave it simple for gradients. If we later want to support
blending between gradient states we can.

One last thing. For .png (or whatever image format) spectra, a
black to white spectrum just be: [black, white] (2 pixels), right? So,
wouldnt' they just be the subset of 'stop' based spectra that have
equidistant stops? (which all spectra can be represented as). In other
words, they'd all get converted into the same format internally, right?