> > 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 <nicolaih...@web.de> wrote: > 2015-03-21 0:19 GMT+01:00 Aliaksei Syrel <alex.sy...@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-broken >> >> 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 > > >
