Broadcast and wait should not yield when dirty until return?

[griffpatch]

Here is a simplified project demonstrating a feature that I use in most of my scratch projects that acts differently in Scratch 2 & 3.

https://llk.github.io/scratch-gui/develop/#184390187

In Scratch 2 you can execute blocks that update the screen and then issue a broadcast and wait without the Scratch runtime yielding to do a screen update until the broadcast and wait completes.

In Scratch 3 the scratch vm apparently stops to update the screen before the broadcast and wait is issued? This results in projects running at half speed in Scratch 3 even when they are doing very little.

Another interesting issue... Try the project on turbo mode. It then runs at 30fps exactly... But remove the broadcast and wait and it jumps to run at 2730 fps. Now in Scratch 2 it runs super fast with the broadcast and wait as well as without. So something about broadcast and waits appear to be holding up turbo mode too?

More Info

I have identified that it is not to do with loops. See: http://llk.github.io/scratch-vm/#184430433
In this project, if it runs at 30fps, then both cats should 'just' pass the line.

Turbo Off, 60fps mode -> Runs at 30fps
Turbo Off, 30fps mode -> Runs at 15fps
Turbo On, 60fps mode -> Runs at 60fps
Turbo On, 30fps mode -> Runs at 30fps

So the questions are, why does a broadcast and wait cause the turbo mode to yield? And why do we get two yields instead of one when running without turbo.

Steps to Reproduce

Try this project in Scratch 2 and Scratch 3.

https://llk.github.io/scratch-gui/develop/#184390187

Operating System and Browser

Windows 10 Chrome

[thisandagain]

@mzgoddard This might be a good / low hanging issue to prioritize.

[paulkaplan]

I have a slightly simplified repro of the "broadcast and wait always yielding":
https://llk.github.io/scratch-gui/develop/#184450398

This project runs very slowly, even though in 2.0 it runs at full speed.

[paulkaplan]

I believe this may be related to this issue? #688

[griffpatch]

I'm not sure... although I did wonder about that... but do broadcast and
waits actual use promises? I couldn't find anywhere obvious that linked
into the promises from the broadcast and wait code...

[griffpatch]

Ok, so I have a fix for this, although I'm not sure if there are any ramifications.

See comit: 1b1bfed

When a broadcast and wait executes, it ends up in an unending loop doing the same checks over and over for 1/60th of a second because the thread is active, but the thread.stack is an empty list.

If you add the empty stack check to the isActiveThreads then all the issues go away. I was quite amazed at the improvement as I was actually able to play turrican 2 in scratch 3 at 60fps!! Too fast!!. (https://griffpatch.github.io/scratch-vm/#174671513 - note, once green flag clicked, you need to click on the Scratch VM Playground title to allow keyboard control.)

isActiveThread (thread) {
    return thread.stack.length > 0 && this.threads.indexOf(thread) > -1;
}

I think this in combination with your recent optimisations has made things unbelievably better! Well done guys, this is astonishing ;)

Griffpatch

[paulkaplan]

Oh wow cool @griffpatch. I do wonder if that check should go inside of isActiveThread or if it should just be another condition in that some function

[griffpatch]

Yes, I don't know either, please do have a rummage and see if you can fathom it... I don't have a lot of time to look deeper, but after debugging a while this was my first idea to try that might work...

…

On 6 Nov 2017 22:02, "Paul Kaplan" ***@***.***> wrote: Oh wow cool @griffpatch <https://github.com/griffpatch>. I do wonder if that check should go inside of isActiveThread or if it should just be another condition in that some function — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#760 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGbNvj7PsJpumm2Zc2XyP7cfLrWkC6IKks5sz4HfgaJpZM4QS62R> .

[mzgoddard]

@paulkaplan @griffpatch broadcastAndWait and switchBackdropAndWait are the only parts of the vm that use isActiveThread. The current test checks if the thread is in the list of current runtime.threads. runtime.threads is not updated until the end of Sequencer.stepThreads after which scratch is going to do a render update and wait for the next frame.

Seems like there are three solutions:

1. Filter out done threads (execute considers threads with a stack length of 0 or with a status of DONE to be non-active) after each outer loop in Sequencer.stepThreads.
2. Add a new method for blocks to call to test if a thread is complete the same way as stepThreads.
3. Do option 2 in isActiveThreads.

I think the best option would be to test if a thread is active the same way Sequencer.stepThreads does (option 3).