Another NuScratch issue

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Another NuScratch issue

Yoshiki Ohshima-3
 
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:


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?

--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

Re: Another NuScratch issue

timrowledge
 


> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> 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?

>
> 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.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Several nuts over fruitcake minimum.


Reply | Threaded
Open this post in threaded view
|

Re: Another NuScratch issue

Yoshiki Ohshima-3
 


On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:
 


> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> 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.

--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

Re: Another NuScratch issue

Yoshiki Ohshima-3
 


On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima <[hidden email]> wrote:


On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:
 


> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> 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.

--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

Re: Another NuScratch issue

Yoshiki Ohshima-3
 


On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima <[hidden email]> wrote:


On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima <[hidden email]> wrote:


On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:
 


> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> 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..)
--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

Re: Another NuScratch issue

Yoshiki Ohshima-3
 


On Sat, Nov 21, 2020 at 9:42 AM Yoshiki Ohshima <[hidden email]> wrote:


On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima <[hidden email]> wrote:


On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima <[hidden email]> wrote:


On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:
 


> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Another NuScratch issue

timrowledge
In reply to this post by Yoshiki Ohshima-3
 
OK, just tried this on my built-last-week ARM64 VM on a Pi 4 and BouncingAtoms happily bounce. 300 -> throttled, 3000 -> 11fps.

The code for handleEvents() in this VM is the same as you posted. Apparently (if we trust 'guthub desktop') I last downloaded any sources on Oct 16 (or as I prefer to think of it, March 230th). Maybe that provides a useful check point.

> On 2020-11-21, at 9:32 AM, Yoshiki Ohshima <[hidden email]> wrote:
>
> 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.


The only weirdness about my setup that might, just possibly, affect this is that my Pi are all connected to my iMac with VNC; none have local displays.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Put a lens in each ear and you've got a telescope.


Reply | Threaded
Open this post in threaded view
|

Re: Another NuScratch issue

Yoshiki Ohshima-3
 


On Sat, Nov 21, 2020 at 11:40 AM tim Rowledge <[hidden email]> wrote:
 
OK, just tried this on my built-last-week ARM64 VM on a Pi 4 and BouncingAtoms happily bounce. 300 -> throttled, 3000 -> 11fps.

Ok... How about ARM32? If that makes a difference, it may be about the complex ifdefs in aioPoll() that somehow fails to capture the case.

 

The code for handleEvents() in this VM is the same as you posted. Apparently (if we trust 'guthub desktop') I last downloaded any sources on Oct 16 (or as I prefer to think of it, March 230th). Maybe that provides a useful check point.

> On 2020-11-21, at 9:32 AM, Yoshiki Ohshima <[hidden email]> wrote:
>
> 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.


The only weirdness about my setup that might, just possibly, affect this is that my Pi are all connected to my iMac with VNC; none have local displays.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Put a lens in each ear and you've got a telescope.




--
-- Yoshiki

Reply | Threaded
Open this post in threaded view
|

Re: Another NuScratch issue

Eliot Miranda-2
In reply to this post by Yoshiki Ohshima-3
 
Hi Yoshiki,

  Levente replaced the select code with epoll code on Linux a fey weeks ago.  Maybe there’s a regression.

_,,,^..^,,,_ (phone)

On Nov 21, 2020, at 10:28 AM, Yoshiki Ohshima <[hidden email]> wrote:




On Sat, Nov 21, 2020 at 9:42 AM Yoshiki Ohshima <[hidden email]> wrote:


On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima <[hidden email]> wrote:


On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima <[hidden email]> wrote:


On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge <[hidden email]> wrote:
 


> On 2020-11-20, at 3:10 PM, Yoshiki Ohshima <[hidden email]> 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

Reply | Threaded
Open this post in threaded view
|

Re: Another NuScratch issue

Levente Uzonyi
 
On Sat, 21 Nov 2020, Eliot Miranda wrote:

> Hi Yoshiki,
>
>    Levente replaced the select code with epoll code on Linux a fey weeks
> ago.  Maybe there’s a regression.

That is indeed the culprit. epoll_wait expects the timeout in milliseconds
but the value is in microseconds. Unfortunately, fixing that brings back
the old increased cpu usage.


Levente