<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/12/19 <span dir="ltr"><<a href="mailto:btc@openinworld.com" target="_blank">btc@openinworld.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">Nicolas Cellier wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger...<br>
So it's the best we can do, while keeping an efficient format.<br>
<br>
But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used.<br>
Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none.<br>
<br>
I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color.<br>
But did not change the rgb ComponentMax... Any reason why?<br>
<br>
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.<br>
But I don't know if it is really inter-operable, or more natural...<br>
<br>
Juan followed another path for Cuis, opting for float components, which is another possibility, but our VM are not yet optimized for handling Floats...<br>
<br>
Thoughts?<br>
</blockquote></div></div>
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.<br>
<br>
cheers -ben<br>
<br></blockquote><div>Yes, it would be sufficient, but it seems simpler to manage a separate 8 bit alpha channel as it is the case now.<br></div></div><br></div></div>