Smalltalk › Squeak › Squeak VM

iOS VM problems with dragging a morph and PasteUpMorph>>flashRects:color:

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

3 messages Options

Javier Diaz-Reinoso

iOS VM problems with dragging a morph and PasteUpMorph>>flashRects:color:

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.

johnmci

Re: iOS VM problems with dragging a morph and PasteUpMorph>>flashRects:color:

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 <[hidden email]> 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
===========================================================================

Javier Diaz-Reinoso

Re: iOS VM problems with dragging a morph and PasteUpMorph>>flashRects:color:

I first tested the sync change, but that don’t work, the program only show a white screen.

Using your code I put a breakpoint in the dispatch_sync and tested for a few minutes, but the breakpoint don’t activate, so I suppose the call is always in the main thread.

On Oct 26, 2015, at 19:48, John McIntosh <[hidden email]> wrote:

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 <[hidden email]> 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
===========================================================================