I would not change the alpha at all. Instead, set alpha 255 in setPrivateRed: r green: g blue: b
It makes sense to be consistent. However blindly setting it to 255 is sometimes unexpected too: Color transparent + Color transparent is assume to get Color transparent and not black. Maybe for + we could add alphas, but for subtraction take the smallest alpha of two colors? Cheers, Alex On Sat, Mar 21, 2015 at 12:32 AM, Nicolai Hess <nicolaihess@web.de> wrote:
2015-03-21 0:19 GMT+01:00 Aliaksei Syrel <alex.syrel@gmail.com>:
Hi,
I played with colors and found out, that arithmetical operations with colors are completely broken.
https://pharo.fogbugz.com/f/cases/15188/Color-ariphmetical-operations-are-br...
Result is not a valid Color - just garbage. It happens because alpha is not being initialized and stays nil. It seems that operation were implemented before alpha support was added. So I propose the following solution:
Color red - Color red = Color transparent
(Color white alpha: 1) - (Color white alpha: 0.5) = (Color white alpha:
0.5)
R,G,B are subtracted as before. Alpha channels are subtracted too.
Color red + Color blue = Color magenta
Color red + Color transparent = Color red
(Color white alpha: 0.5) + (Color white alpha: 0.5) = (Color white alpha:
1)
R,G,B are added as before. Alpha channels are added too.
Multiplication and division by number doesn't change alpha channel.
Cheers, Alex
I would not change the alpha at all. Instead, set alpha 255 in setPrivateRed: r green: g blue: b