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

Re: [E-devel] Premultiply or not

On Tue, Jun 27, 2006 at 08:11:18AM +0000, jose_ogp@juno.com wrote:
> > 
> > Maybe the 2.5 case you mentioned above? Evas in 100% premul terms
> > and edje / higher level apis not? (or 2.25 - which includes an
> > additional non-premul api to evas for convenience)
> > 
> > --
> > brian
> > 
> 	How about 2.5, with the extra addition of a simpler
> mechanism for obtaining "non-premul grads" kinds of results
> as suggested above (although you could do this by generating
> the spectrum yourself in non-premul space, premul the result
> and pass it to the grad api via the grad 'data_set' api func).
> 	One is then free to have libs which decide to have
> interfaces with premul, or non-premul, or a combination,
> as they see fit... and evas will be able to support them.
>    jose.

I think we should at least provide a set of functions for converting
image data / color values between the two spaces. (Sure, its simple op,
but its just nicer imo to have one function call abstracting it away).
So, if people want/need non-premul image data they could just do
something like

  DATA32 *data = evas_object_image_demultiply(evas_object_image_data_get(o));

and conversely something like:

  evas_object_image_data_set(o, evas_image_data_premultiply(data));

for setting data.
Essentially this is what evas would have to do anyway if we kept the API
non-premul. This way its (almost) as convenient, while explicitly making
the programmer aware of the color space transformation.