raku-community-modules/Color

clamping on colors should be done when the values are asked

Opened this issue · 3 comments

There are some blending operations which have intermediate color values exceeding their maximum or minimum values and are clamped to their maximum or minimum. A suggestion is to postpone the clamping until the values are asked for using the to-string methods and others.

A piece of code shows that operations can result in wrong values

my Color $b .= new('#08f');
my Color $c .= new('#8f0");
my Color $r1 = ($b + $c)/2;                    # '#447F7F'
my Color $r2 = $b/2 + $c/2;                   # '#44C37F'

The value of $r2 is the correct one but it needs more operations to get it right. There might be operations which are not that easy to circumvent and always deliver a wrong result.

Regards,
Marcel

🤓 In the code, I saw a lot of clip-to() actions. Moving them to the output routines would also have a positive performance effect.

I'm not yet familiar enough with Color, could you give an example of such a change?

This modification seems a bit touchy without really rebuilding the API of this distro - the assumption seems to be everywhere that whatever a Color object holds at any moment is valid for RGB(A). I think this can be faked by writing accessor methods for all the data a Color object holds - meaning, any access to data in a Color object would settle the values.

What I don't know yet is if this breaks down on too many premature data accesses - that would basically mean that Color objects still finalize immediately, except in a more obfuscated way.