On Thu, 14 Sep 2006 06:55:20 GMT "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
babbled:
>
> Just a note on the evas move-to-premul stuff. Some things
> are taking me a bit more time than I had thought, so it looks like
> I may not finish with it til the weekend.. we'll see.
>
> Let me give a quick recap of the api funcs that this change
> will involve.
>
> There are four utility functions for converting colors and
> argb data to/fro premul:
>
> "evas_color_premul(int a, int *r, int *g, int *b)"
> "evas_color_unpremul(int a, int *r, int *g, int *b)"
> "evas_data_argb_premul(unsigned int *data, unsigned int len)"
> "evas_data_argb_unpremul(unsigned int *data, unsigned int len)"
good - useful routines :)
> Now, as far as evas objects go, grads were the most affected
> by this premul change, and there are new funcs as a result:
>
> "evas_object_gradient_alpha_add(obj, int a, int distance)"
> "evas_object_gradient_alpha_data_set(obj, void *alpha_data,
> int len)"
>
> which allow for adding separate alpha stops and setting separate
> alpha data on a grad ('alpha_data' must have unsigned char values).
> Note that you can have different sets of color and alpha
> stops, and also color and alpha data of different lengths.
>
>
> 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.
nicer - yes.
> The original reason for having this 'data unset' function
> was to make it clear that you could not add colors to the gradient
> *on-top-of* data that had been set.. but that isn't really a good
> enough reason to have it, and in practice the use of this function
> is cumbersome.
yup- as they both do the same. keep it to 1 :)
> Also, when I get another chance, there'll be a func for
> setting a 'file/key' on a grad so that one will be able to load grad
> spectra, eg. gimp grads, etc. and then one would be tempted to have
> a 'file-unset' func just for logical similarity... and it's just
> not worth it.
or as per the image obj - just set the file to NULL to unset. :)
> So unless someone really strongly feels otherwise, I'd say
> let's take this 'gradient-data-unset' function out now.
agreed. :)
> Ok, besides that, I wanted to fix some of the issues that
> Brian had with grads in edje...
>
> For this, I thought the best thing to do is to separate
> the notions of the 'grad-angle' and the 'grad-fill-angle'.
>
> So, I've added a new grad fill related api func:
>
> "evas_object_gradient_fill_angle_set(obj, Evas_Angle angle)"
>
> which does what the current "evas_object_gradient_angle_set" now
> does, ie. rotate the fill region, and the grad-angle-set func will
> instead do what it used to do - namely it will orient the gradient
> (rel to the fill now) at that angle and make it 'cover' the fill
> region. I've only implemented it for linear grads, but it's actually
> intuitive for 'linear' kinds of geoms.. eg. for sinusoidal and such.
sounds ok to me.
> It can also be given a reasonable interpretation for most
> any geom, and in fact might be useful for images as it could be
> taken to mean 'rotate the image' before using it in the fill (the
> fill itself has its own rotation.. as will the object as a whole...
> there's much angleness here).
not sure what you mean here (well not precisely).
> I've also added two new linear grad types: "linear.diag" and
> "linear.codiag", which orient themselves rel to the fill's diagonal
> and co-diagonal (when the grad-angle value is 0).
>
> Lastly, I've added an api function to set the grad spectrum
> 'direction':
>
> "evas_object_gradient_range_direction_set(obj, int direction)"
>
> where 'direction' should be 1 or -1. This will reverse the gradient
> spectrum if set to -1.
>
> Much ado about gradients, but hopefully all this will make
> it easier to work with grads in current edje and otherwise.
>
> Comments...?
sounds good - one thing i did notice - gradient fills are a lot slower than
images... :) i noticed when cross-fading wallpapers @ 1600x1200 with gradient
bg's :)
--
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) [EMAIL PROTECTED]
裸好多
Tokyo, Japan (東京 日本)
-------------------------------------------------------------------------
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
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
