<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2013/12/20 David T. Lewis <span dir="ltr"><<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Moving this to vm-dev for discussion of the BitBlt primitive.<br>
<br>
On Fri, Dec 20, 2013 at 02:13:29AM +0100, Nicolas Cellier wrote:<br>
> 2013/12/20 Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>><br>
><br>
> ><br>
> > On 20.12.2013, at 00:55, Nicolas Cellier <<br>
> > <a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>> wrote:<br>
> ><br>
> > 2013/12/13 Nicolas Cellier <<a href="mailto:nicolas.cellier.aka.nice@gmail.com">nicolas.cellier.aka.nice@gmail.com</a>><br>
> ><br>
> >> I feel like it would be better to change pixelValueAt: so as to always<br>
> >> unhibernate, but I did not dare if ever someone had the idea of sending it<br>
> >> in tight loops (one shouldn't, there is BitBlt for that purpose, but who<br>
> >> knows...).<br>
> >><br>
> >> Maybe we could fail primitivePixelValueAt if receiver is Byte like, and<br>
> >> unhibernate in fallback code.<br>
> >> We would let every other BitBlt primitives accept a ByteArray to allow<br>
> >> BitBlt tricks.<br>
> >><br>
> >> Thoughts?<br>
> >><br>
> >><br>
> > No one raised a comment so far.<br>
> > Isn't it a good idea to fail the primitive?<br>
> ><br>
> ><br>
> > The primitive must fail, yes. That is simply a bug. Before that primitive<br>
> > existed, pixelValueAt: used BitBlt which did the unhibernate.<br>
> ><br>
> > If yes, then it's very simple to implement, just add:<br>
> ><br>
> > (interpreterProxy isWords: bitmap) ifFalse:[interpreterProxy<br>
> > primitiveFail].<br>
> ><br>
> ><br>
> > IMHO the primitive should do the same check as BitBlt: verify that the<br>
> > size of the bits is exactly right given width, height, and depth.<br>
> ><br>
> > - Bert -<br>
> ><br>
><br>
> I opened <a href="http://bugs.squeak.org/view.php?id=7799" target="_blank">http://bugs.squeak.org/view.php?id=7799</a> just in case.<br>
><br>
<br>
Thanks for opening the <a href="http://bugs.squeak.org" target="_blank">bugs.squeak.org</a> issue. Your patch adds this:<br>
<br>
bitsSize := interpreterProxy byteSizeOf: bitmap.<br>
((interpreterProxy isWordsOrBytes: bitmap)<br>
and: [bitsSize = (stride * height * 4 "bytes per word")])<br>
ifFalse: [^interpreterProxy primitiveFail].<br>
<br>
Which translates as:<br>
<br>
bitsSize = interpreterProxy->byteSizeOf(bitmap);<br>
if (!((interpreterProxy->isWordsOrBytes(bitmap)) && (bitsSize == ((stride * height) * 4)))) {<br>
interpreterProxy->primitiveFail();<br>
return null;<br>
}<br>
<br>
This looks like exactly what Bert was suggesting.<br>
<br>
I think there are two things we should test:<br>
<br>
1) Check if the extra computation has an effect on performance.<br></blockquote><div><br></div><div>I don't think the difference will be measurable, that's very few ops overhead...<br></div><div>Even if it was, it must be compared to in-image protection alternative.<br>
So I don't think that this is relevant in this case.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
2) Check to make sure the logic works on the 64 bit image, to make sure<br>
that the 4 bytes per word does the right thing (I think that it will work,<br>
and I can follow up on this later to be sure).<br>
<br>
Dave<br>
<br></blockquote><div> </div><div>The 4 bytes per word is also hardcoded in other BitBlt primitive because that's really what the bit blt expect, 32bit words.<br></div><div>I'm a bit puzzled by 64bits image terminology, is variableWordSubclass: composed of 32bits words or 64 bits words (like pointers)?<br>
</div></div><br><br></div></div>