[Vm-dev] iOS VM problems with dragging a morph and PasteUpMorph>>flashRects:color:

John McIntosh johnmci at smalltalkconsulting.com
Tue Oct 27 00:48:40 UTC 2015


Ok, I have to look at this, the issue is: Is the thread on the background
thread or the main thread. I suspect a thread check  isMainThread is
needed. If so then queue the draw. Otherwise do the draw request. I note
that this only tells the UIKit to ask the view controllers to draw *later*
That would occur next time thru the main event loop.

try this and see what happens.

if ([NSThread isMainThread]) {
                [[self getMainView] drawThelayers];
} else {
dispatch_sync(dispatch_get_main_queue(), ^{   //note try sync not async, I
wonder if that would be an issue?
                [[self getMainView] drawThelayers];
   });
}

Note the old code was

if ([NSThread isMainThread])
[[self getMainView] drawThelayers];
else {
[[self getMainView] performSelectorOnMainThread: @selector(drawThelayers)
withObject: nil waitUntilDone: NO];
}

On Mon, Oct 26, 2015 at 10:09 AM, Javier Diaz-Reinoso <javier_diaz_r at mac.com
> wrote:

>
> As i reported in the Squeak list I find a bug with dragging a morph and in
> PasteUpMorph>>flashRects:color:, I find the problem is with the
> implementation of DisplayScreen>>forceDisplayUpdate in the VM, specifically
> in ioForceDisplayUpdateActual in sqSqueakScreenAndWindow.m, the actual
> implementation call drawTheLayers using a queue:
>
>     dispatch_async(dispatch_get_main_queue(), ^{
>                 [[self getMainView] drawThelayers];
>    });
>
> I find this is unreliable, calling directly to drawTheLayers the bug is
> corrected, I believe that this is the correct operation because what you
> want is an immediate update otherwise the “timing” of the operation is
> lost, like in PasteUpMorph>>flashRects:color:, between the first and second
> call to copyBits are only 15 milliseconds, I suppose is the same with the
> drag of a morph.
>
> I don’t know if this change create new problems, appears to be working OK
> in an iPad2 (32 bits) and a iPad mini (64 bits).
>
> By the way I tested also using [SqueakUIViewOpenGL class] instead of
> [SqueakUIViewCALayer class] in whatRenderCanWeUse, that works OK in the
> iPad2 but create a small image in the iPad mini, I think is not taking into
> account the 2X of the retina display.




-- 
===========================================================================
John M. McIntosh. Corporate Smalltalk Consulting Ltd
https://www.linkedin.com/in/smalltalk
===========================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20151026/3d27b5f6/attachment.htm


More information about the Vm-dev mailing list