blend function urgently needed in kdelibs

Matt Newell newellm at blur.com
Tue May 22 01:34:59 BST 2007


On Monday 21 May 2007 17:09, Matthew Woehlke wrote:
> Aaron J. Seigo wrote:
> > On Monday 21 May 2007, Matthew Woehlke wrote:
> >> David Faure wrote:
> >>> On Tuesday 22 May 2007, Matthew Woehlke wrote:
> >>>> Seven parameters (hehe... actually it's going to be eight) are pretty
> >>>> well required if it's to be flexible
> >>>
> >>> Another solution is to create a KColorBlender class, with a number of
> >>> setter methods and a blend() method (without arguments - i.e. the "do
> >>> it now" method)... OK not sure it makes sense, just thinking out loud
> >>> about how to avoid 8 params :)
> >>
> >> ...which is actually how OpenGL works, so the thought /had/ crossed my
> >> mind :-). And... I might think about it more. I can actually see a
> >> KColorBlend class with blend(c1, c2, k, r) with k,r optional and reusing
> >> preset values, but I don't see taking it as far as not even needing the
> >> input colors. I guess my real question is, does the additional memory
> >> used justify it?
> >
> > 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.  

This is just off the top of my head, and double precision probably isn't 
required, but this would only be 48 bytes or less i think.

private:
ColorSpace cs;
union {  double r; double h; }
union { double g; double s; }
union { double b; double v; double y; double l; }
double a;
KColorPrivate * d; // Always 0 until a real need for KColorPrivate
};


Matt

PS. I'm no colorspace expert, so don't flame me if this is all wrong.




More information about the kde-core-devel mailing list