blend function urgently needed in kdelibs

[Matthew Woehlke]

Aaron J. Seigo wrote:
> On Monday 21 May 2007, Matthew Woehlke wrote:
>> Aaron J. Seigo wrote:
>>> On Monday 21 May 2007, Matthew Woehlke wrote:
>>>> Matthew Woehlke wrote:
>>>>> kdelibs desperately needs a color blending function. I am volunteering
>>>>> (yet again) to provide one that looks like this:
>>>>>
>>>>> KColor blend(const KColor& c1, const KColor& c2,
>>>>>              double k = 0.5, double r = 0.5, SPEC cs = CS_RGB,
>>>>>              int flags = BLEND_NORMAL, int cmask = 0x0000FFFF);
>>>>>
>>>>> Can someone PLEASE suggest where I can put such a thing? (Due to lack
>>>>> of prior response, if I don't hear back by next Monday I'm going to
>>>>> /pick/ somewhere and people can bitch about it.)
> 
> i'll echo tzander's request for more readable API. 7 parameters is also a bit 
> crazy, but perhaps that's unnavoidable for this. graphics programming 
> sucks ;) but at least we can get proper parameter names; and BLEND_NORMAL 
> should of course be NormalBlend or whatever, CS_RGB RgbColorSpace, etc...

Don't worry, that's from an old draft, I'll be using e.g. BlendNormal. 
Seven parameters (hehe... actually it's going to be eight) are pretty 
well required if it's to be flexible; often you use only three of them 
but... well really all of them are needed.

Although having thought about it further I think I will axe cmask... 
it's *freaking* complicated and is really begging to turn into something 
like three parameters all by itself. I think instead I'll look at 
providing e.g. KColor::multiply( <various signatures> ), so that if you 
really, really need fine-grain control, you can do it in a few steps 
rather than a monolithic and over-engineered blend(). (Whew.)

So often you need three parameters, and blend without three parameters 
is useless, so... Occasionally you will use six, /maybe/ seven. It's 
still seven because flags is going to become mode and flags. But I might 
even drop flags; haven't decided on that yet.

And yes, this looks (should look) a lot like OpenGL color blending with 
the added joy that k and r don't come from the colors' alpha channels, 
and extended to more color spaces.

> what does the cmask (colour mask?) do?

Well, it controls which channels k and r affect, this is needed (see 
above) for certain blend modes to work "right" (for some definitions of 
right), but I think I'll just hard-code that based on the spec.

> this will all be easier with an actual implementation to comment on, of 
> course.

A long, long time ago I actually posted one. :-)

Ah, here it is: http://lists.kde.org/?l=kde-core-devel&m=116593466331981&w=2

That also gives some explanation of what the heck the flags, cmask, etc. 
are for.

>> I'm mainly concerned that if the usability stuff doesn't happen *now* it
>> won't happen until KDE5, as it isn't clear if there will be BC issues.
>> And it /won't/ happen without blend() in kdelibs.
> 
> ok... perhaps we can take this as the primary use case for this then.

I don't think I necessarily agree with that :-) but it's a fine starting 
point for conversation, so...

> what sort 
> of class do you see the usability colour palette stuff ending up in? would it 
> also be KColor? or some other class?

No, some other class; actually I think the usability stuff will all be 
static methods. Anyway, as previously mentioned I don't think blend() 
should be in the same file as the usability stuff, I think of it as an 
independent function that the usability stuff makes use of.

> if the latter, then perhaps that should 
> be where this goes vs having a class with one public method?

Actually it will have a /lot/ more public methods, probably more than 
QColor, because it will have accessors for HSL/HSY color spaces. And 
multiply(), etc. And it will have at least three static methods 
corresponding to class methods (where 'this' is the first argument of 
the statics).

>> ...And for the usual "if it isn't in 4.0 no one will use it" reason. :-)
> 
> well, that's only half the equation. the other half is identifying apps 
> that -will- use it, but only if it is in kdelibs. i think you've managed to 
> do that.

Ok, and thanks. :-)

-- 
Matthew
When in doubt, duct tape!