2013/12/19 Bert Freudenberg <bert at freudenbergs.de>

>
> 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 -
>
>
Yes, that's why we would need to invert the encoding of alpha channel...
But this change would be much more intrusive (change primitives...), and
not really compatible with established practices where alpha channel is
interpreted as opcity level, not as transparency level (
http://en.wikipedia.org/wiki/RGBA_color_space)
I think we can forget this part of the proposition which is too much
Smalltalk-centric.

Nicolas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131219/b853fc87/attachment.htm