blend function urgently needed in kdelibs
mw_triad at users.sourceforge.net
Mon May 21 23:33:26 BST 2007
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
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.
>> 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
>> ...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. :-)
When in doubt, duct tape!
More information about the kde-core-devel