Hello nicolas

> I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger...
> So it's the best we can do, while keeping an efficient format.
> 
> But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used.
> Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none.
> 
> I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color.
> But did not change the rgb ComponentMax... Any reason why?

No special reason. We just started to clean the code to understand it and avoid isKindOf: and because we thought
that there is no need to have color and translucent colors anymore. 

> If we encoded rgb component on 8 bits, and reverted the alpha channel encoding, then we could have colors pre-encoded on 32 bits, but most using only 24 bits (because most are opaque) would be represented as SmallInteger.
> But I don't know if it is really inter-operable, or more natural…

Thanks for the discussion. Now do you have an idea about the speed gain?
> 
> Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats...
> 
> Thoughts?