From: Brian M. <bri...@gm...> - 2006-05-19 15:05:27
|
On Friday 19 May 2006 09:18, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : moom > Project : e17 > Module : proto > > Dir : e17/proto/etk/data/themes/default/widgets > > > Modified Files: > colorpicker.edc > > > Log Message: > * More work on the colorpicker, but it's still incomplete and a bit > buggy. > > It now uses its own optimized hsv <--> rgb conversion procedures from > Jose. I haven't committed them to Evas because, for optimization > purpose, they do not check if the params are valid. > Thanks Jose :) I was curious just how much of an optimization leaving off null checks was, so i did a quick profile. Loop through all r,g,b values (0..255) and call rgb_to_hsv, then loop through all h,s,v values (0..360), diving s and v by 360 and call hsv_to_rgb first is without null checks (as in etk) second adds null checks rephorm@boru ~/code $ time ./prof real 0m4.521s user 0m4.500s sys 0m0.004s rephorm@boru ~/code $ time ./prof2 real 0m4.578s user 0m4.544s sys 0m0.008s This is on an athlon 64 3000+ So, adding in null checks is about a 1% slowdown. Is that really enough to care about? (Has the added benefit of letting the functions work if you just need one value and don't want to create temp vars for the others -- e.g. rgb_to_hsv(r,g,b,h,NULL,NULL) -- rephorm |