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

[E-devel] Premul move -- decisions and such

	Ok, lets see if we can decide on this.. so that actual work
can be done :)

	I'll outline below my current proposal for moving evas over
to alpha premul color space.

	But before doing so, let me note that we don't have to do
this in order to have an xrender engine which is consistent with the
software engine.
	We could re-work the xrender engine to use alpha masks..
ie. we now take non-premul image data, we premultiply it and hand
it to xrender for all image compositing+transforms, which is what
gives the current conflict with the software engines.. We could
instead take our non-premul data and put the alpha channel to a
separate mask, and hand this pair, opaque color data + separate
alpha mask, to xrender for compositing+transforms.
	This would work, but it will be somewhat slower and more
involved when doing color multipliers and such.. but it can be made
to work.

	This would allow evas to remain purely within the realm
of non-premul color space and have more-or-less the same results
with the xrender engine as with the software engine.

	The benefits of this would of course be that there would
be no "pain" on any of the current apps/libs using evas.
	The detriments are a klunky, slower, more limited rendering

	[[ I should add that in an earlier later I decried the "svg,
pdf,..." specs as having "screwed-up".. and while I stand by this as
far as the svg spec goes, in all truth I'd never even looked at the
pdf spec! I downloaded the thing and took a quick look at it and
I have to say that pdf seems quite consistent in what it does.
It's entirely non-premul based, even the compositing model is
strictly non-premul... It does mean some slowness, some limitations,
some added complexity in their multiple 'masks', etc.. But it is
very coherent. ]]


	If instead evas moves to an entirely premul color space,
we would have as benefits somewhat faster engines all around, and
a simpler, more powerful rendering model.
	The main detriment is of course some pain for current stuff,
and much fighting and arguing about just what to do.

	Now, here's my proposal for moving evas to alpha-premul-

	1. No current api structural changes, but rather a change in
the color-space semantics to premul:
	Specifically, all current api functions that accept input
(r,g,b,a) color data will now asume this to be premul, and similarly
pixel related 'data-set/get' funcs (eg. image, grad ones) will assume
the data to be premul.
	The evas buffer engine will also now assume that all argb32
pixel formats consist of premul data (but one could also give an option
to import/export non-premul such), and all the image loaders would
premul their data if need be.

	2. Additional 'utility' functions for converting between
premul and non-premul colors/data:
  evas_color_rgb_a8_premul(int *r, int *g, int *b, int a);
  evas_color_rgb_a8_unpremul(int *r, int *g, int *b, int a);

  evas_data_argb32_premul(unsigned int *data, int len);
  evas_data_argb32_unpremul(unsigned int *data, int len);

which would allow one to convert premul/non-premul colors and data
as desired.

	3. Additional gradient api functions:
  evas_object_gradient_alpha_add(Evas_Object *grd,
                                 int alpha, int dist);
  evas_object_gradient_alpha_data_set(Evas_Object *grd,
                                      void *mask, int len);

which would allow for generating both premul and non-premul spectrums
in a more powerful way (the color and alpha spectrums, if there, would
be generated separetly, then multiplied to obtain a single resulting

	But it does mean that in order to obtain what is now done
with non-premul r,g,b,a:
  evas_object_gradient_color_add(grd, r,g,b,a, dist);
you would instead need to do:
  evas_object_gradient_color_add(grd, r,g,b,255, dist);
  evas_object_gradient_alpha_add(grd, a, dist);
to obtain the same results.

	In general, if at some point later in time one may want to
add geometric objects that have colors associated with vertices
or such, one would want a similar pattern.. ie. the ability to set
a (premul) color *and* possibly a separate alpha.

	For example, say we want to add the ability to specify a
'color' to each endpoint of a line object... we would then have
not only the setting of a premul (r,g,b,a) color at each endpoint,
but also the setting of a separate alpha value there.

	It's a bit more complex, but it allows for linear
interpolation of 'alpha+color' in *both* premul and non-premul
contexts while remaining withing a single color space and
compositing model for both colors and data.


	Additional related things I would consider of interest:

	4. Add the ability to get/set an alpha-mask to image
	5. Add support for more "imported" color spaces --
eg. other yuv/yuva formats, cmyk, hsv, etc.. via the current
"evas_object_image_pixels_import" api func. Also, consider an
"export" version of this function.

	Simon suggests:

	6. Modified image api funcs of the form
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);

	Carsten suggests:

	7. Add image api funcs of the form
void evas_object_image_colorspace_set(Evas_Object *obj,
                                      Evas_Colorspace colorspace);
Evas_Colorspace evas_object_image_colorspace_get(Evas_Object *obj);