<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, May 1, 2017 at 5:25 PM, tim Rowledge <span dir="ltr"><<a href="mailto:tim@rowledge.org" target="_blank">tim@rowledge.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Err, yeah, that’s old stuff. So far as I can dredge up from long-term storage RISC OS has not likely problem with this because I have to copy the bits from the Display to the window backing store with a transform (ARGB-> 0BGR)  which means I couldn’t simply extract pixels at any time other than ioShowWindow(). The cost is two copies of the Display bitmap sitting around, which is a bit painful.<br>
<br>
This is presumably an issue when a vm has threads for event handling of assorted OS stuff like window changes? Isn’t this something that pinning is supposed to help? And surely the BitMap is just about certain to be in old space?<br></blockquote><div><br></div><div>As I said, even of the bits are pinned, the current access coder has to go through the specialObjectsArray.  Look at the code I posted.  Any of those fetchPointerofObject cals could cause an error mid way through a become or compact.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5"><br>
> On 01-05-2017, at 3:50 PM, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
> Tim, John, Bert, et al,<br>
><br>
>     if you look at e.g. resizing code in the platforms/iOS code (in e.g. platforms/iOS//vm/OSX/<wbr>sqSqueakOSXOpenGLView.m) the code accesses the display bits by looking up the display object installed via primitiveBeDisplay in the specialObjectsArray:<br>
><br>
> - (void) performDraw: (CGRect)rect {<br>
>     sqInt form = interpreterProxy-><wbr>displayObject(); // Form<br>
><br>
>     CGContextRef context = (CGContextRef)[[<wbr>NSGraphicsContext currentContext] graphicsPort];<br>
>     CGContextSaveGState(context);<br>
><br>
>     int width = interpreterProxy-><wbr>positive32BitValueOf(<wbr>interpreterProxy-><wbr>fetchPointerofObject(1, form));<br>
>     int height = interpreterProxy-><wbr>positive32BitValueOf(<wbr>interpreterProxy-><wbr>fetchPointerofObject(2, form));<br>
>     sqInt formBits = interpreterProxy-><wbr>fetchPointerofObject(0, form);   // bits<br>
>     void* bits = (void*)interpreterProxy-><wbr>firstIndexableField(formBits); // bits<br>
>     int bitSize = interpreterProxy->byteSizeOf(<wbr>formBits);<br>
>     int bytePerRow = 4*width;<br>
><br>
> This is really unsafe.  If it gets called while the VM is compacting, or doing a become, then potentially boom!<br>
><br>
> Storing the display in the specialObjectsArray stops it form being GCed, but it doesn't stop it moving around, and it doesn't stop a become altering the location of the objects surrounding it, etc.<br>
><br>
> Surely a better approach is to inform the VM of the location, depth and extent of the bits via some ioSetDisplayBits function and then cacheing those values somewhere in the VM.  Thoughts?<br>
><br>
> P.S.  John McIntosh tells me that you, Tim R, may have written such code in the past.<br>
><br>
> _,,,^..^,,,_<br>
> best, Eliot<br>
<br>
<br>
</div></div>tim<br>
--<br>
tim Rowledge; <a href="mailto:tim@rowledge.org">tim@rowledge.org</a>; <a href="http://www.rowledge.org/tim" rel="noreferrer" target="_blank">http://www.rowledge.org/tim</a><br>
Strange OpCodes: WK: Write to Keyboard<br>
<br>
<br>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>