[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [E-devel] Premultiply or not
On Mon, 3 Jul 2006 23:19:05 +0200 Simon TRENY <email@example.com> babbled:
> On Tue, 4 Jul 2006 00:11:10 +0900,
> Carsten Haitzler (The Rasterman) <firstname.lastname@example.org> wrote :
> > every edje design (.edc's) that specifies a color for text or solids,
> > clips etc. any app that sets an object color itself. there are 74
> > calls to evas_object_color_set in e17. e17's creation of netwm icons
> > would need to do a premul step. 54 in edje. more in ewl, etk etc.
> > etc. now with edje - do we force the .edc's to specify colors in
> > premul? if so there are (evil) 666 instances of colors in e17's
> > default theme - or do we have edje_cc convert to premul on encode -
> > or do we have edje turn into premul runtime?... how far do you go? :)
> Etk doesn't often use evas_object_color_set() so it will be really easy
> to port. For .edc files, I really think the colors should remain
> non-premul RGBA colors since .edc files are made by graphic designers, and
> designers are used to non-premul RGBA colors (graphic tools give
> non-premul colors). And using premul colors will really make theming
> painful imho since themers often try different color settings to see
> which setting is the best looking. With premul colors, the themers would
> have to convert to premul colors each time they would like to change a
that's a good point. i guess .edc's should stay non-premul. i would then say -
convert runtime as converting JUST colors is really simple and painless and
it's not going to be overhead worth worrying about.
> Now, whether edje_cc should convert to premul on compilation or do it on
> runtime, I don't really know. Maybe it could be done during the compilation,
> so it'll save some work during runtime.
> Also, what do you think of having an API like that for image_data_set/get()?
> 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);
actually i was thinking
void evas_object_image_colorspace_set(Evas_Object *obj, Evas_Colorspace
Evas_Colorspace evas_object_image_colorspace_get(Evas_Object *obj);
the setting of the colorspace will then determine the ARGB pixel format you set
or get (and also then allow setting of YUV too later trivially with direct
access). this would not break the api at all :)
> The "colorspace" param in the data_set() func describes the colorspace
> of the given data, and in data_get(), it describes the colorspace in
> which you'd like to get the data. The colorspace in which it's stored
> by Evas could depend on the engine (it could be "colorspace" if the
> engine is optimized for "colorspace", or another more adapted colorspace).
> Perhaps that is what you were already discussing with Jose, I haven't
> understood very well.
well actually i was thinking ALL engines would use premul ARGB by DEFAULT unless
you tell them that you want to get/set pixel data in another colorspace (yuv,
yuva (planar, interleaved etc.), non-premul argb etc. etc.). IF the engine CAN
handle the format natively (eg some yuv formats if we have xvideo accel) then
the engine will avoid any conversion internally and deal with it as-is. if it
cannot - then it will convert as needed internally.
> Simon TRENY <MoOM>
------------- Codito, ergo sum - "I code, therefore I am" --------------
The Rasterman (Carsten Haitzler) email@example.com
Tokyo, Japan (東京 日本)