On Sun, 2 Jul 2006 12:00:03 +0200 Simon TRENY <simon.treny@...> babbled:
> On Sun, 2 Jul 2006 12:35:34 +0900,
> Carsten Haitzler (The Rasterman) <raster@...> 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
> > and a EVAS_COLORSPACE_ARGB and that leads to EVAS_COLORSPACE_YUVA as
> > 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!! :)
ok - with a lot of time, thinking, other things to occupy me, etc. i have
actually given this thought.
here is my current view.
1. i think we can handle a switch to premul for argb pixel data and color_set
and gradients etc. edje itself would translate non-premul to premul when
loading an edje config file as non-premul makes more sense to humans (artists)
as it is what they are used to.
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) raster@...
Tokyo, Japan (東京 日本)