[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Premultiply or not
On Thu, 29 Jun 2006 08:24:48 -0500 email@example.com babbled:
Ok - time to jump in on this thread.
1. premultiply does speed things up in the internal engine. it also would speed
up dealing with xrender as we then deal in xrender's native ARGB colorspace.
premul makes sens from many viewpoints.
2. yes - it WORKS differently to non premul space. it literally is a different
colorspace with alpha and a transition from 1 colors that vary alpha in premul
does NOT work (always) the same as non-premul. thats how it works. a lot of
points within a linear traversal in premul and non-premul space can be linear,
but others can't. as simon pointed out - that is a case where the linear path
in premul does not match non-premul. this is something i think we can live
3. premul solves some of our existing up and downscaling problems where we
interpolate the COLOR to whatever rgb is off in the blank pixel next to a
solid pixel. you will notice sometimes blackish halos or sometimes colored
ones. it depends on the source pixels loaded. often you don't notice - but
it's something i have noticed and this fixes it with no performance impact
(and actually speedups).
4. xrender works in premul. right now when copying evas pixel data to xrender
we need to do a premul process. its not very optimised, but it works and goign
to premul internally will allow us to save this step IF the source image fromat
is premultiplied (i will add eet code to do this actually as then edje files
with image data can have all the data already pre-processed).
5. changing the pixel format to premul wont impact a lot - only things that
directly access image ARGB pixels via get/set data will be affected, and then
only if they use the alpha channel.
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.
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.
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) firstname.lastname@example.org
Tokyo, Japan (東京 日本)