blend function urgently needed in kdelibs

[Matt Newell]

On Monday 21 May 2007 18:14, Matthew Woehlke wrote:
> 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
All of qt is a ("strange") mix of d-ptr'd code, no problems there.

> - the private members must remain forever (until KDE5)
So, it's not like rgb and hsv are going to become obsolete next year.  When 
was the last time a new color space was invented?

> - not totally relevant, but I was going to hang the colorspace
> conversion code off of KColorPrivate
This makes no difference.

> - no implicit sharing (this might be a good idea...)
Yeah, a good idea for classes who's data is too large to pass around on the 
stack with decent performance...

>
> 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.red()
> kd.hue()
> kc.blue()
> kc.hue()
>
> ...now 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 :-))
>
I disagree.  If you are going to have a color class that can represent 
multiple color spaces, the correct way to do it is to store it in the color 
space the color is given in, and convert it when requested.  It's the 
application programmers responsibility to know what functions are going to 
cause conversions when, since some colors can only be represented in some 
color spaces...

What i'm saying is exactly how qt's QColor works.

   union {
        struct {
            ushort alpha;
            ushort red;
            ushort green;
            ushort blue;
            ushort pad;
        } argb;
        struct {
            ushort alpha;
            ushort hue;
            ushort saturation;
            ushort value;
            ushort pad;
        } ahsv;
        struct {
            ushort alpha;
            ushort cyan;
            ushort magenta;
            ushort yellow;
            ushort black;
        } acmyk;
    } ct;

...
void QColor::getHsvF(qreal *h, qreal *s, qreal *v, qreal *a) const
{
        if (!h || !s || !v)
        return;

    if (cspec != Invalid && cspec != Hsv) {
        toHsv().getHsvF(h, s, v, a);
        return;
    }

etc.

Matt