[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Evas Gradients
On Sun, 11 Jun 2006 07:18:12 GMT "firstname.lastname@example.org" <email@example.com>
> > > 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? :)
> Yes :) Only a preliminary version for now. It's unfortunate
> though that most 'formats' don't really separate the notion of a
> "spectrum" from the fuller notion of a "gradient".
> In fact, only the Gimp's "ggr" definition really seems to
> give this concept the 'first class' status it ought to have. All
> other descriptions that I ran across (after very limited searching)
> relegate the concept to something residing within a gradient, but not
> really capable of standing alone it seems.
> > > 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 :)
> Yes. Also, some comments you made have started me thinking
> that, regardless of the file format, it might be best to simply have
> 'spectrum' loaders as just another kind of image loader.. so that
> spectrums are loaded as w x 1 sized images (for argb color spaces
> at least), where w is a certain canonical length..
yup - it's simple and generic. and "w" is simply what in the end determines
spectrum quality. :)
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) firstname.lastname@example.org
Tokyo, Japan (東京 日本)