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

Re: [E-devel] Premultiply or not

On Sun, 2 Jul 2006 12:35:34 +0900,
Carsten Haitzler (The Rasterman) <raster@rasterman.com> wrote :

> what i think might be best is we:
> 1. add internal premul to non-premul and back conversion routines
> (need them anyway - may as well make them fast).
> 2. need to add calls to image objects to get/set the COLORSPACE of
> the internal object data (the default would be premul and the
> suggestion would be to leave it alone unless you have very special
> needs). 3. move default colorspace to ARGB_PREMUL (we can have
> non-premul space, but it will need conversion to premul before using
> in routines). 4. i think the best might be we have a
> evas_colorspace_set(evas, EVAS_COLORSPACE_ARGB_PREMUL); for example
> well so then evas can do the conversion (if needed) when setting the
> color of an object on that canvas. this will mean we can port
> existing code with 1 function call when creating the canvas (set it
> to the non premul argb). perhaps also per object too (an objects
> specific colorspace overrides the evas one).
> then we can begin a migration of code over to premul and remove the
> call - but still keep it there for the ability to switch into a more
> convenient colorspace. i am not sure this colorspace should affect
> image pixels though... that should be per image object as above.

I don't really like the idea of having a couple of functions,
evas_colorspace_set/get() to change the global colorspace of evas. In
my opinion, it will confuse the things a bit more and will make the
implementation harder. For example, if I start in the colorspace
EVAS_COLORSPACE_ARGB_PREMUL, I set the colors of the objects, the data
of the images, and then, I switch the colorspace EVAS_COLORSPACE_ARGB.
What do I get when I'll try to get the colors or the data of the
objects? Converted colors or the old premul colors? Another confusing
situation with edje: if I render an edje object in the ARGB_PREMUL
colorspace, will it look the same in the ARGB colorspace (i.e. will
Edje directly evas_object_color_set() or will it convert the color?)

Imho, the colorspace in which the data of an image is internally stored
by Evas should depend on the engine used. For example, the software and
the xrender engines should store it in premul colors, the OpenGL engine
should store it in "normal" colors (since I don't think you can have a
premul argb texture, but I'm probably wrong) and a XV engine (stupid
idea...) should store it in YUV colors. That way, it will be stored the
most efficient way in order to be rendered efficiently. There must be
some scaling issues but I dont think that storing in an unique
colorspace would solve it (since you'll have to do the conversion
sooner or later, probably before the scaling transform if you want to
benefit from the optimizations of the engine).

So I think that an API like that could be good:
void evas_object_image_data_set(Evas_Object *obj, void *data, Evas_Colorspace colorspace);
void *evas_object_image_data_get(Evas_Object *obj, Evas_Colorspace colorspace, Evas_Bool for_writing);

So it's up to the user to choose the colorspace, (using ARGB_PREMUL to
avoid a conversion with the 2 most common engines: software and
xrender), and he can't be confused since it's he who makes the choice.

Now, there is the problem of evas_object_color_set(). Imho, we have to
choose, either we ask always for a premul color or always for a
non-premul color, but I don't really like the idea of having a function
evas_colorspace_set() to switch the current colorspace (and I don't
like the idea of having a colorspace by object too). And if we'll have
to choose, I'm still for non-premul colors!! :)

Regards, :)
Simon TRENY <MoOm>