<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/12/20 Frank Shearar <span dir="ltr"><<a href="mailto:frank.shearar@gmail.com" target="_blank">frank.shearar@gmail.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">On 20 December 2013 00:34, <<a href="mailto:commits@source.squeak.org">commits@source.squeak.org</a>> wrote:<br>
> Nicolas Cellier uploaded a new version of Graphics to project The Trunk:<br>
> <a href="http://source.squeak.org/trunk/Graphics-nice.282.mcz" target="_blank">http://source.squeak.org/trunk/Graphics-nice.282.mcz</a><br>
><br>
> ==================== Summary ====================<br>
><br>
> Name: Graphics-nice.282<br>
> Author: nice<br>
> Time: 20 December 2013, 1:34:17.553 am<br>
> UUID: 89166f93-3989-4cbd-aa5e-14f949960b9b<br>
> Ancestors: Graphics-nice.281<br>
><br>
> 1) Fix initialization of a Form bits. the guard against wrong bitsSize were never invoked on new instances.<br>
><br>
> 2) Accelerate a bit Color>>pixelValueForDepth:,<br>
> 2.a) Most frequent usage nowadays is for 32 bits depth, so raise this case to the top.<br>
> 2.b) the guard against rgb=0 being used for marking transparent can be factored out<br>
> (Note that Squeak was not the only app. to use this trick, like explained at<br>
> <a href="http://en.wikipedia.org/wiki/Palette_%28computing%29#Transparent_color_in_palettes" target="_blank">http://en.wikipedia.org/wiki/Palette_%28computing%29#Transparent_color_in_palettes</a>)<br>
> 2.c) The (LargeInteger new: 4) trick is now more straightforward thanks to 2.b)<br>
> Note 1: the normalize could be replaced by yourself in 32 bits images,<br>
> but the futur never were so close than now ;) - I mean Spur<br>
> Note 2: I check that using SmallInteger arithmetic and final LargeIntegerization is slower, COG or not.<br>
> So the (LargeInteger new: 4) trick will stay a while longer.<br>
> It would be more efficient to reduce Color componentMax to: 255.0, then use a single + 16rFF000000...<br>
><br>
> 3) Guard more Form bits inst. var. access with unhibernate.<br>
> This was not applied to pixelValueAt: because this message is used inside tight loops,<br>
> and it would be preferable (more efficient) to fail the primitive, and unhibernate in the fallback code.<br>
><br>
> 4) Classify a few methods exclusively used by PostScript generation under 'postscript generation'.<br>
> I know they virtually could be used for something else, but there's enough API to digest and classification helps.<br>
> It will be time to unclassify eventually if ever someone send those messages<br>
><br>
> =============== Diff against Graphics-nice.281 ===============<br>
<br>
</div></div>I have an idea this broke some PNG tests in GraphicsTests. (Reason:<br>
<a href="http://build.squeak.org/job/SqueakTrunk/701/console" target="_blank">http://build.squeak.org/job/SqueakTrunk/701/console</a> shows<br>
Graphics-nice.281, with the tests passing, while<br>
<a href="http://build.squeak.org/job/SqueakTrunk/702/console" target="_blank">http://build.squeak.org/job/SqueakTrunk/702/console</a> shows<br>
Grpahics-nice.282, with the tests failing.<br>
<br>
(PNGReadWriterTest >> #testPngEncodingColors32, for instance)<br>
<span class="HOEnZb"><font color="#888888"><br>
frank<br>
<br></font></span></blockquote><div>Gah! I don't know how I came to this assertion, 2.b) is completely false... <br></div><div>I will correct this one.<br></div></div><br></div></div>