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

Re: [E-devel] Evas Gradients



On Thu, 25 May 2006 07:33:00 GMT "jose_ogp@juno.com" <jose_ogp@juno.com>
babbled:

> 
> > > >     In the meantime, evas grads could also be enhanced in
> > > > various ways. Here are some that I would like to add sometime
> > > > soon:
> > > >    1. Loading grads from a file - ie. support for whatever
> > > > file formats may exist, or may be defined, for describing
> > > > types and/or spectrums for gradients.
> > > > .....
> > > > .....
> > > > 
> > > >   If anyone has any suggestions/comments/ideas, or whatnot,
> > > > related to 'gradients'... :)
> > > 
> > > I think inkscape, gimp, and a few others have been working on
> > > standards to allow dragging and dropping things like gradients
> > > between their applications, so have a look at the work they are
> > > doing.
> > 
> > like ".grd" files that can describe a gradient? :)
> > 
> 
> 	Yes, both 'drag&drop' and 'thumb-nailing' functionality
> would be something that could be done with gradient file formats.
> 	It should be possible in eg. a file-manager view, for one
> to d&d some grad file and be asked wether to move/copy/... *or*
> set that as the bg.. etc. :)

sure - sounds good.

> 	There are many things that one could include in a file
> format that could "specify" a 'gradient' -- eg. does one want to
> include wether it's a 'radial' gradient.. or other such info.
> 
> 	At its core though, a gradient needs a 1-dimen spectrum
> (multi-gradients need a 2-dimen spectrum), which we may think of
> as a mapping s: [0,1] --> SomeColorSpace, and let's just restrict
> the color space to ARGB32 say.
> 	Clearly there are multitudes such, but common ones are
> simple:
> 
> 	1. Given some ARGB32 data[len], with len > 1, we can
> define a spectrum s by:
>    For 0.0 <= f <= 1.0,  s(f) = data[f*(len - 1)];
> 
> There are 'smoother' ways of doing this, but it gives the basic
> idea.
> 
> 	2. Given a sequence of pairs (col[i], r[i]), 0 <= i <= n,
> where the col[i] are ARBG32 colors, and the r[i] are in [0,1] and
> satisfy
> 	a) r[0] = 0.0, r[n] = 1.0
> 	b) i < j implies r[i] < r[j]
> 
> We can then define a spectrum s by:
>    For s(0.0) = col[0], s(1.0) = col[n], and for 0.0 < f < 1.0,
> let j be the max i with r[i] <= f, and set s(f) to be the linear
> interpolation from col[j] to col[j+1], at f,
>  ie. s(f) = ((r[j+1] - f)*col[j] + (f - r[j])*col[j+1]) /
> 	    (r[j+1] - r[j])
> 
> 	Most definitions that require one to generate the spectrum,
> eg. evas' 'color_add' api, gimp's .grd format, svg grad 'stops',...
> essentially reduce to 2 above (modulo wether the interpolation is
> to be linear or some other).
> 	Even 1 above is a particular case of 2, with n = len - 1,
> col[i] = data[i], and r[i] = 1.0/i, and we use for 'interpolation'
> a sampling method...
> 
> 	Now, one doesn't necessarily compute things this way, but
> the point is that at its core we can import most anybody's spectrum
> descriptions.
> 
> 	We can easily support gimp's '.grd' gradient files (modulo
> funky interpolation methods they like to have for each 'segment'),
> and also svg-doc gradient fragments as well.
> 
> 	So the question for evas is really one of "how much of a
> given format's specifics should we also import..?" (it would be good
> to know exactly what are the known grad related file formats)

i believe you have tackled this by now eh? :)

> 	I believe that evas should only import the spectrum
> (possibly also basic aspects like the color space), all other
> 'higher level' attributes should be left free for the grad api
> to modify (ie. things like the 'type', the 'spread', the 'fill',
> the 'jump and wriggle this or that way...', etc).
> 
> 	We also want to have eet based descriptions - both stand-
> alone and as part of an edje file..
> 	Thus, secondary questions are - what would be a good format
> to use in eet files for spectra defns, and what would be a good
> format for edje gradients that could refer to the former...?

sure. as with eet - you could just put a in-memory data struct of gradient
color points, distances and interpolation method flags. as eet can just decode
direct to your in-memory data struct for you :)

> 	Suggestions are welcome :)
> 
> 
> > > > like ".grd" files that can describe a gradient? :)
> > > > 
> > > I'm not sure of the details, this is recent work and someone
> > > gave a talk about it at my local users group a few weeks ago.
> > >
> > aaah - but i assume there is some "file format" involved.
> > i do hope its not some xml mojo again... 
> 
> 	Man, it's ALL mojo!
> 
> 	Syntax is syntax.. :) What less mojo is there in bash/
> smash/perl/shell scripts, or in the autotools/auto-confusing
> macro-wonderland, or this or that format/language/api/whatever...
> 
> 	To me, the greatest mojo of all is having dozens of them,
> each with their own wonderful %l$O#@L+j<<uT;&if34+=???.???..?????
> 
> 	Programmers are the masters of mojo it seems.. You ought
> to embrace and extend them all with equal love and affection :) :)

grrr xmfuckingl :)

> 
> 
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat certifications in
> the hosting industry. Fanatical Support. Click to learn more
> http://sel.as-us.falkag.net/sel?cmd_______________________________________________
> enlightenment-devel mailing list
> enlightenment-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
> 


-- 
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler)    raster@rasterman.com
裸好多
Tokyo, Japan (東京 日本)