On Mon, 30 May 2016 14:03:43 +0900 Conrad Um <[email protected]> said:
> In Efl layer, there is a data type named as Efl.Gfx.Color which contains > four members (r, g, b, a) & its type (8bits or 16bits). Then why aren't we > using Efl.Gfx.Color instead of 4 integers. > > efl_gfx_color_set(obj, color); // color is Efl.Gfx.Color data structure > > Moreover, inline methods (helper) can be added which passes 4 integers and > returns Efl.Gfx.Color. These helper functions can provide conversion > between premultiplied and straight color. > > evas_object_color_set() uses premultiplied color, but > edje_object_color_set() uses straight one. They are not inconsistent. Even > though EDC uses straight (because it can be used by designer), but using > premultiplied in API level seems more consistent. > I'm making APIs to change the color of Elemenatry widget by using > edje_object_color_class_set() internally, but their name like > evas_object_color_set(). (eg: elm_object_color_set()) > The problem which type of color will be used still exists here. > > Only my concern is that manual conversion between premultiplied and > straight is annoying. This work can be done by helper functions mentioned > above. > Please give your ideas about this. Thank you. well we've used 4 int's because... well.. that's how it's always been. :) doing higher resolution colors doesn't need much special (eg 16bit per rgb) other than a "high dynamic range" api that takes values from 0 to 65535 instead of 0 to 255. so that''s why. now using a single 32bit int for a color instead of r, g, b, a separate values... that's a matter for style. i agree that the api should be premul here. the api reflected what was in the edc side instead of what is considered normal at the api level (for edje colorclasses etc.). the common case in api's is to see r, g, b, a as 4 integers. android, eclipse, java, and others. html popularized a hex version like #ff8800 ... tho really in rgba space that is 0xffff8800 (a is high byte). so there is a possibility to see color as a single 32bit integer ... OR as 4 values (just 4 ints. we could have used 4 unsigned chars just as well but whatever). tbh - i don't know which is better. the single int does have the benefit of efl_color_set(obj, efl_color_premul(input)); just return a premultipled version of a non-premul color. a lot of api's actually like to make whole color objects... with multiple api's on setting them. we have not done that. a whole eo object for color would be ridiculous. a struct with api's to set/fill/get values in various spaces might be ok. but is that a good idea? oh yeah. there is a good reason to stick to 4 ints. javascript and lua. an unsigned int here would have to become a "number" in js and lua. numbers are doubles. while a double can express precision for whole values up to (and beyond) 32bits (unsigned) so it wouldn't be a problem, these languages are going to be far more painful to work in in dividing up r, g, b and a when you have a combined number and then combining them again. in languages with integer types that are at least 32bit this is generally not a problem as they give you bit operators like and/or and bitshift, this is less nice in languages like lua that don't do this. well not out of the box. http://www.lua.org/manual/5.2/manual.html#6.7 much less nice than just having 4 value params. so things begin to look quite ugly here. :( so i think this is one of those times where people need to provide their input, but a single "unsigned int" for a color seems less nice for languages like lua, but it's nicer for returning a color value. > Best Regards, > conr2d (Jee-Yong Um) > ------------------------------------------------------------------------------ > What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic > patterns at an interface-level. Reveals which users, apps, and protocols are > consuming the most bandwidth. Provides multi-vendor support for NetFlow, > J-Flow, sFlow and other flows. Make informed decisions using capacity > planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e > _______________________________________________ > enlightenment-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- ------------- Codito, ergo sum - "I code, therefore I am" -------------- The Rasterman (Carsten Haitzler) [email protected] ------------------------------------------------------------------------------ What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic patterns at an interface-level. Reveals which users, apps, and protocols are consuming the most bandwidth. Provides multi-vendor support for NetFlow, J-Flow, sFlow and other flows. Make informed decisions using capacity planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ enlightenment-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
