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
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?
On 2020-11-20, at 3:10 PM, Yoshiki Ohshima Yoshiki.Ohshima@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:
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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Several nuts over fruitcake minimum.
On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge tim@rowledge.org wrote:
On 2020-11-20, at 3:10 PM, Yoshiki Ohshima Yoshiki.Ohshima@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:
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.
On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge tim@rowledge.org wrote:
On 2020-11-20, at 3:10 PM, Yoshiki Ohshima Yoshiki.Ohshima@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:
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.
On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge tim@rowledge.org wrote:
On 2020-11-20, at 3:10 PM, Yoshiki Ohshima Yoshiki.Ohshima@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:
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..)
On Sat, Nov 21, 2020 at 9:42 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge tim@rowledge.org wrote:
On 2020-11-20, at 3:10 PM, Yoshiki Ohshima Yoshiki.Ohshima@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:
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...
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 Yoshiki.Ohshima@acm.org wrote:
On Sat, Nov 21, 2020 at 9:42 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Sat, Nov 21, 2020 at 9:32 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Fri, Nov 20, 2020 at 5:11 PM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
On Fri, Nov 20, 2020 at 4:50 PM tim Rowledge tim@rowledge.org wrote:
On 2020-11-20, at 3:10 PM, Yoshiki Ohshima Yoshiki.Ohshima@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:
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
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
On 2020-11-22, at 8:50 PM, Levente Uzonyi leves@caesar.elte.hu wrote:
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.
Do we have a decent solution for this issue? It *utterly* ruins NuScratch on a Pi and I'm trying to make a new release. Won't someone please think of the children?
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ETO: Emulate Toaster Oven
On Sun, 13 Dec 2020, tim Rowledge wrote:
On 2020-11-22, at 8:50 PM, Levente Uzonyi leves@caesar.elte.hu wrote:
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.
Do we have a decent solution for this issue? It *utterly* ruins NuScratch on a Pi and I'm trying to make a new release. Won't someone please think of the children?
Just pushed a fix[1]. Let me know if that works.
Levente
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3db3888c2a76bd91ef6...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ETO: Emulate Toaster Oven
Thanks.
I had a workaround but was not for real. Levente's patch works for me.
On Sun, Dec 13, 2020 at 9:35 PM Levente Uzonyi leves@caesar.elte.hu wrote:
On Sun, 13 Dec 2020, tim Rowledge wrote:
On 2020-11-22, at 8:50 PM, Levente Uzonyi leves@caesar.elte.hu wrote:
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.
Do we have a decent solution for this issue? It *utterly* ruins
NuScratch on a Pi and I'm trying to make a new release. Won't someone please think of the children?
Just pushed a fix[1]. Let me know if that works.
Levente
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/3db3888c2a76bd91ef6...
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Strange OpCodes: ETO: Emulate Toaster Oven
On 2020-12-14, at 9:31 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Thanks.
I had a workaround but was not for real. Levente's patch works for me.
It's a big improvement but there is still something making for odd hesitations in Asteroid Blaster; which is obviously one of the most important benchmarks imaginable. Probably not a VM thing though
tim -- tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Earth is 98% full...please delete anyone you can.
Where can I try the Asteroid Blaster? My workaround was just divide the wait time by 1000 and I'm curious to see if that has different effects on a different example.
On Mon, Dec 14, 2020 at 10:01 AM tim Rowledge tim@rowledge.org wrote:
On 2020-12-14, at 9:31 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org
wrote:
Thanks.
I had a workaround but was not for real. Levente's patch works for me.
It's a big improvement but there is still something making for odd hesitations in Asteroid Blaster; which is obviously one of the most important benchmarks imaginable. Probably not a VM thing though
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Earth is 98% full...please delete anyone you can.
I finally dug up the Asteroid Blaster project (thanks to Abe-san) and tried it on the last VM built from the head of Cog branch. I cannot tell the "odd hesitation", Is there something else I should check?
On Fri, Dec 18, 2020 at 10:44 AM Yoshiki Ohshima Yoshiki.Ohshima@acm.org wrote:
Where can I try the Asteroid Blaster? My workaround was just divide the wait time by 1000 and I'm curious to see if that has different effects on a different example.
On Mon, Dec 14, 2020 at 10:01 AM tim Rowledge tim@rowledge.org wrote:
On 2020-12-14, at 9:31 AM, Yoshiki Ohshima Yoshiki.Ohshima@acm.org
wrote:
Thanks.
I had a workaround but was not for real. Levente's patch works for me.
It's a big improvement but there is still something making for odd hesitations in Asteroid Blaster; which is obviously one of the most important benchmarks imaginable. Probably not a VM thing though
tim
tim Rowledge; tim@rowledge.org; http://www.rowledge.org/tim Earth is 98% full...please delete anyone you can.
-- -- Yoshiki
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 Yoshiki.Ohshima@acm.org 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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Put a lens in each ear and you've got a telescope.
On Sat, Nov 21, 2020 at 11:40 AM tim Rowledge tim@rowledge.org 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 Yoshiki.Ohshima@acm.org
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; tim@rowledge.org; http://www.rowledge.org/tim Useful random insult:- Put a lens in each ear and you've got a telescope.
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Levente Uzonyi -
tim Rowledge -
Yoshiki Ohshima