blend function urgently needed in kdelibs

[Matthew Woehlke]

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

-- 
Matthew
When in doubt, duct tape!