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

Re: [E-devel] Premultiply or not

	Carsten writes:

> 1. ......
> 5 .......

	The troubles of having evas' software engine do transforms
in premul color space whereas the render engine does so in premul
are only seen so far if you look carefully or try to do certain
things.. But they are a very deep inconsistency and makes evas
basically worthless for any serious consideration of these
engines as more or less 'interchangeable'.

> 6. the problem we have is for evas_color_set() and then edje
> and nigh everything that depends on this. if we go premul for
> this just about everything will break and need fixing. this is
> a lot of stuff.

	Having edje pass premul colors to evas would be trivial.
If that's all apps/libs are using then they wouldn't have to do
a thing.

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

	What good would that do for all but the software engines
(and possibly the gl engine). You can't make render do transforms
with data in non premul colorspace - one'd just be back to the
situation that exists now except with two sets of compositing
(and other drawing) routines in the software engine.

> 3. move default colorspace to ARGB_PREMUL (we can have non-premul
> space, but it will need conversion to premul before using in
> routines).

	What is the point of having a color space that you can't
do gfx with internally except convert it to premul?
	Only if all the evas engines could work with both premul
and non premul color space in their gfx handling routines would
this make any sense.. and it would still be highly suspect to
be able to use this coherently.

> 4. i think the best might be we have a evas_colorspace_set(evas,
> 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).

	What's the point of having this in the canvas when such
color spaces can't be used directly in a coherent way?
	You already have the YUV import call, and what does it
do? Convert to rgb since there's no internal support by any
of the engines to composite ayuv with argb. Not only that, but
there are questions of coherence when it comes to using transforms
that are not easily dealt -- just as now you have two different
results from scaling data with the software vs the render engines
when the results are rendered. Are you prepared to do scaling/shearing
etc. in ayuv space prior to compositing - how will you have render
do this right now? Have you thought out the results of what this
will lead to vs first converting to rgb and then scaling/shearing..?
Which one(s) you want and why?
	This is why I didn't want to add eg. an api func for
adding ahsv colors to grads, and instead had the interpolation
happen there.. I could imagine setting such an interpolation
color space to be premul argb/ayuv, non premul argb/ayuv, etc.
But there needs to be good reason.. and even more for having other
color-space *entry* points. That colors can come in different
color spaces alone is not good enough reason - conversion funcs
are for that.

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

	It all sounds very nice... set the color space as you wish,
per object even.. :)  But it's not so nice when you look deeper.
	I would consider some of this to be partially viable
only when the main engines you want to use (software and render)
are capable of dealing with transforms and compositing in these
color spaces.. Otherwise it's nothing but an inconsistent mess.