blend function urgently needed in kdelibs

[Robert Knight]

> 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.

That doesn't make sense.  You are taking 3 to 6 parameters, presumably
no more than 8 bytes each and putting them into a class.  Where does
this > 180 figure come from?

Regards,
Robert.


On 22/05/07, Matt Newell <newellm at blur.com> wrote:
> 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.
>