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

Igor Stasenko siguctua at gmail.com
Thu Dec 19 18:04:44 UTC 2013


i can go even further: why we can't just have 3 inst vars for Color
(red,green,blue)
+ alpha in case of transparency and be done with it :)
and if we get rid of unused cachedDepth cachedBitPattern,
the space in memory for Color intance(s) won't get much higher,
(if it makes any sense to care about it).

i guess that any change in color storage format will involve changing VM
primitives (bitblt plugin and friends), where operations with color involved



On 19 December 2013 18:12, Bert Freudenberg <bert at freudenbergs.de> wrote:

>
> On 19.12.2013, at 18:06, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> 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?
>
>
> All opaque colors would be LargeIntegers, not SmallIntegers: 16rFFxxxxxx.
>
> - Bert -
>
>
>
>
>
>


-- 
Best regards,
Igor Stasenko.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131219/714e1ebd/attachment.htm


More information about the Squeak-dev mailing list