<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/12/25 Stéphane Ducasse <span dir="ltr"><<a href="mailto:stephane.ducasse@inria.fr" target="_blank">stephane.ducasse@inria.fr</a>></span><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Hello nicolas<br>
<div><br>
> 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>
</div>No special reason. We just started to clean the code to understand it and avoid isKindOf: and because we thought<br>
that there is no need to have color and translucent colors anymore.<br>
<div><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>
</div>> But I don't know if it is really inter-operable, or more natural…<br>
<br>
Thanks for the discussion. Now do you have an idea about the speed gain?<br></blockquote><div><br></div>Absolutely no idea.<br><div><div>BitBlt is rich enough (color maps or direct
color components, depths, endianness) to make this unpredictable by
simply analyzing sender chain in source code (it's too deep and
convoluted).<br></div><div>The best way is to try it, but then one must
choose a benchmark, and here again it is a difficult decision, because
maybe you didn't bench a path that some other use intensively, how to
guess without above analysis?<br><br></div><div>I saw those un-necessary mismatch while analyzing Graphics code...<br></div><div>By a principle of economy, I suggest to remove them.<br></div><div>Simplifying code a little bit is already a win.<br>
<br></div>Then, les petits ruisseaux font les grandes rivières, cumulated micro optimizations may pay.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div><div>><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>
<br>
<br>
</div></div></blockquote></div><br></div></div>