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

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Thu Dec 19 18:06:07 UTC 2013


2013/12/19 <btc at openinworld.com>

> 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
> complexity.
>
> cheers -ben
>
> Yes, it would be sufficient, but it seems simpler to manage a separate 8
bit alpha channel as it is the case now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131219/b120106e/attachment.htm


More information about the Squeak-dev mailing list