[Pharo-dev] Why Color rgb components are on 10 bits?

btc at openinworld.com btc at openinworld.com
Thu Dec 19 12:33:56 EST 2013

Nicolas Cellier wrote:
> 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?
> 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...
> 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?
Could 6 bits be enough for transparency?  Perhaps only for Pharo's own 
system & UI stuff.  Any bitmap editor application would probably need to 
extend to handle the full 8 bit alpha.  Or maybe that adds unneeded 

cheers -ben

More information about the Pharo-dev mailing list