<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2013/12/19 Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</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">
<div dir="ltr"><div><div>i can go even further: why we can't just have 3 inst vars for Color (red,green,blue)<br></div>+ alpha in case of transparency and be done with it :)<br></div><div>and if we get rid of unused cachedDepth cachedBitPattern,<br>
</div><div>the space in memory for Color intance(s) won't get much higher,<br></div><div>(if it makes any sense to care about it).<br></div><div><br></div>i guess that any change in color storage format will involve changing VM primitives (bitblt plugin and friends), where operations with color involved<br>
<br></div></blockquote><div><br></div><div>If it is just Color, then no primitive change is necessary, Juan did it in Cuis, and he his using Floats (or rather FloatArray).<br></div><div>If it's the encoding of Bitmaps then sure, it's another matter (so let's forget about inverting the alpha channel encoding).<br>
<div><br></div><div>Packing rgb in a single SmallInteger is an optimization.<br></div>But sure, while at it, we can also question the packing.<br>How many Colors are stored in the system, how many short lived colors are created during graphics operations?<br>
<br>To judge whether this is really necessary or not, we have to measure the costs of various solutions in term of memory/CPU...<br></div><div>My proposition was a sort of local optimum in the neighbourhood of current implementation, keep an efficient packing, but avoid unecessary conversion in most used case (32 bit depth).<br>
</div><div><br>Most colors are held by the color map (colors) of ColorForm,
but this usage is already mitigated because those colors are often
encoded as WordArray already, not as Array of Color (well it depends,
and code isn't crystal clear currently).<br><br></div><div>For clarity of code, it should not change much as long as we do not optimize too many messages and keep using self red, self green, self blue instead of direct ivar access.</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 dir="ltr"></div><div class="gmail_extra"><div><div class="h5"><br><br><div class="gmail_quote">
On 19 December 2013 18:12, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><div><br><div><div>On 19.12.2013, at 18:06, Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com" target="_blank">nicolas.cellier.aka.nice@gmail.com</a>> wrote:</div>
<br><blockquote type="cite"><div><div dir="ltr"><div><div><div><div>I know the answer, we have 30 bits available for keeping the rgb instance variable as SmallInteger...<br></div><div>So it's the best we can do, while keeping an efficient format.<br>
<br>
</div>But we are never using 10 bits for each component, for 32 bits image only 8 bit by color are used.<br></div>Since nowadays most Forms are 32 bits deep, this force useless conversions where we could have none.<br><br>
</div><div>I see that Pharo 3.0 did unify Color and TranslucentColor by moving the alpha information in Color.<br></div><div>But did not change the rgb ComponentMax... Any reason why?<br></div><div><br></div>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><div>But I don't know if it is really inter-operable, or more natural...<br><br></div><div>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></div><div>Thoughts?</div></div></div></blockquote><br></div></div></div><div>All opaque colors would be LargeIntegers, not SmallIntegers: 16rFFxxxxxx.</div><span><font color="#888888"><br><div>
<span style="border-collapse:separate;border-spacing:0px;font-family:'Lucida Grande';font-size:12px"><div style="font-family:Helvetica"><span style="font-family:Helvetica">- Bert -</span></div><br></span>
</div>
<br></font></span></div><br><br>
<br></blockquote></div><br><br clear="all"><br></div></div><span class=""><font color="#888888">-- <br>Best regards,<br>Igor Stasenko.
</font></span></div>
<br><br>
<br></blockquote></div><br></div></div>