blend function urgently needed in kdelibs

Matthew Woehlke mw_triad at
Tue May 22 02:14:32 BST 2007

Matt Newell wrote:
> On Monday 21 May 2007 17:09, Matthew Woehlke wrote:
>> Aaron J. Seigo wrote:
>>> we're talking about 2 color objects and 2 doubles, right? that shouldn't
>>> be a problem.
>> ok... sizeof(KColor) == sizeof(void*), it has a d-ptr (it NEEDS a
>> d-ptr!). sizeof(KColorPrivate) == 80 at least; more if/when more color
>> spaces are supported. So that's an overhead of at least 184 bytes...
>> because people think 3-6 args to a function is too many? That was the
>> question. :-) I'm willing to be convinced, but personally I'm not
>> bothered by 3-6 args...
> Not that it makes a huge difference, but why not make the members private and 
> have a d-pointer set to 0 for now.  Then at least the object can be allocated 
> on the stack.  Also, if the class is KColor, then shouldn't it only hold the 
> actual color information?  It seem 80 bytes is overkill unless there's 
> something I'm missing.  

Well, let's see...
- if it is extended, there is a strange mix of private and d-ptr'd code
- the private members must remain forever (until KDE5)
- not totally relevant, but I was going to hang the colorspace 
conversion code off of KColorPrivate
- no implicit sharing (this might be a good idea...)

80 bytes comes from 10 channels of information: alpha, red, green, blue, 
hue, saturation(hsv), saturation(hsl/hsy), value, luminance, and luma. 
And that's with no CMYK support. Also it's 84 bytes (my bad), I will 
probably have a mask of which channels are valid to improve performance. 
You *could* cut it down to 36 as you pointed out, but then if you ever 
have code like this...
kc.hue() you're converting back and forth all the time :-( and you only 
saved 48 bytes. (Also, with a d-ptr *now* we can tweak such 
implementation details without breaking BC :-))

Anyway this is all excellent stuff to consider, but it's also SC so we 
have Mondays until release to decide which is better :-).

When in doubt, duct tape!

More information about the kde-core-devel mailing list