[Vm-dev] Another NuScratch issue

Yoshiki Ohshima Yoshiki.Ohshima at acm.org
Sat Nov 21 18:27:53 UTC 2020


On Sat, Nov 21, 2020 at 9:42 AM Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
wrote:

>
>
> On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
> wrote:
>
>>
>>
>> On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
>> wrote:
>>
>>>
>>>
>>> On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <tim at rowledge.org> wrote:
>>>
>>>>
>>>>
>>>>
>>>> > On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <Yoshiki.Ohshima at acm.org>
>>>> wrote:
>>>> >
>>>> > So I built a new VM with a  fix  for the input method change.  I did
>>>> not fully test the other things but Scratch on the VM does not do
>>>> animations. It updates screen only when mouse is moved, or some slower
>>>> interval:
>>>> >
>>>> > https://photos.app.goo.gl/QHgKCeeP2bnQGESu5
>>>>
>>>> That's really weird. I see two systems running at the same time there -
>>>> same image? Different VM?
>>>>
>>>
>>> Yeah, those are running the same image on different VMs.
>>>
>>>>
>>>> >
>>>> > I suspect that there might have been some options I needed to pass in
>>>> to specify some timers?  Can you think of other reasons why this might
>>>> happen and where to look to fix it?
>>>>
>>>> I never had any timer related options to worry about, so it shouldn't
>>>> be anything to do with that.
>>>>
>>>> What happens if you use the 'new' VM but don't use the compositor/input
>>>> thing? IIRC I had terrible problems caused by that ibus program and we had
>>>> to make sure it didn't get into the Raspbian release.
>>>>
>>>
>>> I'll check it out. I wasn't expecting this kind of problem and did not
>>> fully test things out.
>>>
>>
>> Not having compositioninput does not fix the problem. With a non-scratch
>> image and I run BouncingAtomsMorph, the screen update on my VM is one frame
>> per second unless I move the mouse pointer.
>>
>> Which function to obtain the current time to tell the VM to run the next
>> event loop? I can check if it is called.
>>
>
> One datapoint is that making the  argument for aioSleepForUsecs
> in display_ioRelinquishProcessorForMicroseconds() to be always zero:
>
> static sqInt display_ioRelinquishProcessorForMicroseconds(sqInt
> microSeconds)
> {
>    aioSleepForUsecs(handleEvents() ? 0 : 0);
> // aioSleepForUsecs(handleEvents() ? 0 : 1000);
>   return 0;
> }
>
> makes it run smoothly. So the return value from handleEvents() would have
> to make sense.
>
> (still investigating..)
>

So the handleEvents() looks like this:

--------------------
int handleEvents(void)
{
  if (recordPendingKeys())
    return 0;

  if (!isConnectedToXServer || !XPending(stDisplay)) {
    return !iebEmptyP();
  }

  while (XPending(stDisplay))
    {
      XEvent evt;
      XNextEvent(stDisplay, &evt);
      handleEvent(&evt);
    }
  return 1;
}
--------------------
but the part that affecting the animation performance is "return
!iebEmptyP()". If I take out "!", it tells the caller that it handled an
event when (?) not collected to the X server (which is a weird test) or not
X event is not pending, check if the input event buffer is empty or not.

This check may be okay but needs some clarifications.

But I suspect that aioSleepForUsecs() on this platform may be sleeping
given milliseconds and not microseconds. That may be consistent with the
symptom of waking up at every second...

-- 
-- Yoshiki
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20201121/091c5e48/attachment-0001.html>


More information about the Vm-dev mailing list