[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Premultiply or not
> Imho, the colorspace in which the data of an image is internally
> stored by Evas should depend on the engine used.
This is an interesting idea in its own but I would say that
it's not one that evas is really ready to pursue at this point..
It could be something to consider later though.. :)
One can still have engines though that might only use some
of the functionality available, etc.
> 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
I don't know a thing about OpenGL, just glanced at parts
of the api on a couple of ocassions.. but I believe that associating
data with textures in OpenGl depends only on the depth of the data
and the color order (ie. argb, bgra,...). The actual blending func
used seems to be set by setting various blend modes...??
> 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).
There could be transform issues if the data is manipulated
prior to compositing, but not if it's all simply "imported" into
a common format and all manipulation done there.
Any format that is linearly equivalent to the common format
could be manipulated directly in its original version, so long as one
restricts to linear transformations you would get the same result
as if you converted first and then did the linear transformations.
> 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
That would work, but it's not really necessary.. There's
already an import api function which covers more or less the same
ground -- it's only really used for importing yuv formats right now
(and indeed the importing of anything else is disabled), but it can
be easily extended to import (and export) ARGB32_NON_PREMUL data and
whatnot. Right now, the import api func will always make its own
internal data from the given inputs, so it always acts like 'make
a copy' rather than directly using the given input.. but I suppose
it might be possible to extend it to allow for 'direct' use of the
inputs in some cases..
The data-set api funcs are for simple, fast access using the
'native' data format.
Is there some particular case in etk that you feel you
have some problem with?
> 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>
Why is everybody so hung up on this 'color-set' so badly
that they just can't let the damn non-premul color thing go...
You can have this at higher levels, and also premul as
well then, and actually do more things.. and loose nothing if you
just want to restrict yourself to non-premul colors....