On Thu, 25 May 2006 07:33:00 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]<<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) [EMAIL PROTECTED] 裸好多 Tokyo, Japan (東京 日本) _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
