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.
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@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.
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 johnmci@smalltalkconsulting.com 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 <javier_diaz_r@mac.com mailto:javier_diaz_r@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 https://www.linkedin.com/in/smalltalk
vm-dev@lists.squeakfoundation.org
-
Javier Diaz-Reinoso -
John McIntosh