[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] evas premul changes
On Thu, 14 Sep 2006 16:36:51 GMT "firstname.lastname@example.org" <email@example.com>
> > > Since we're 'breaking' stuff and going over things -- I went
> > > ahead and *removed* the current "evas_object_gradient_data_unset"
> > > api function.
> > >
> > > Why..? Well, its functionality can be obtained by setting
> > > new data/adata, or by the colors-clear api func (which will clear
> > > alpha stops as well), or just by adding new color/alpha stops.
> > >
> > Maybe we should just name the function evas_object_gradient_clear()?
> > (since it'll clear color/alpha stops, data or image depending on
> > which was set, if i'm understanding properly)
> Yes, that's what it does. Also, if you add a color/alpha
> stop and there's data/alpha_data or a file set, it would remove these
> latter, etc.
> But yes, I guess a more generic 'gradient-clear' name would
> be better than the current 'colors-clear' (though it might be taken
> to mean 'clear' the type as well).
> However, if we're going to do that, then maybe just go ahead
> and rename some others.. eg. 'grad-fill-spread' instead of the current
> 'grad-spread', and 'grad-stop-add' instead of 'grad-color-add', and
> 'grad-alpha-stop-add' instead of 'grad-alpha-add'
> I guess a lot of these should have 'spectrum', but that's
> so damn long.. which is why I used 'range' instead for the "offset"
> and "direction" properties.
> I'll leave it up to you and Carsten if you wish -- you're
> the 'namespace' overlord.. something highly needed. :)
it's a close call. in clearing the gradient type - it doesn't clear but reset
to a default - so i would stick with colors-clear as it clears the set of
colors as such. - that's my take on it, but there is something to be said of
the simpler "grad-clear" so to speak :)
> > > .....
> > > .....
> > This makes a lot of sense to me. It cleanly maps to edje, and
> > gives all the functionality I can currently think one would want
> > (without the hackish feel of my current 'solution' in edje.
> What you did was actually fairly ideal if one were dealing
> exclusively with linear grads (and evas had similar).
> But yes, I think the above may work fine with the generic
> gradient&fill interfaces.
> > > ...
> > > where 'direction' should be 1 or -1. This will reverse the
> > > gradient spectrum if set to -1.
> > Is this ignored for 'image' gradients?
> No, the spectrum will be reversed regardless of its source..
> ie. wether it's from stops/data/file. It's done internally when
> the interpolating ocurrs.
> > > Much ado about gradients, but hopefully all this will make
> > > it easier to work with grads in current edje and otherwise.
> > >
> > > Comments...?
> > Very awesome stuff. Thanks! :)
> Very straightforward really.. some "physics" stuff someone
> started looks like far more awesome stuff :)
> But it should improve things with grads a bit. Most of the
> actual reworking had to do with the premul change and the separate
> color/alpha stuff... and with various improvements I took the chance
> to do - more acurate spectrum generation, fix the type-params parsing
> so it only ocurrs when the params actually change, and some other
> There's still a lot left to do with grads - add the file
> setting, add "foci" params to radial and angular grads, maybe
> add a 'stop-mode' function for setting wether the "distance" used
> in stops should be interpreted as 'weights' or as 'dist-to-next',
> and many other things (eg. optimizations)...
> But I have to get out of gradient-land soon, I'm starting
> to get tired of them.
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> enlightenment-devel mailing list
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) firstname.lastname@example.org
Tokyo, Japan (東京 日本)