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

[E-devel] evas premul changes

	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)"

	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.

	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.
	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.

	So unless someone really strongly feels otherwise, I'd say
let's take this 'gradient-data-unset' function out now.

	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.
	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).

	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

   "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.