Support framerates higher than 250 for faster I/O event handling

[FurryR]

Resolves

See Reason for Changes.

Proposed Changes

This Pull Request refactors (entire) frameLoop to allow meaningful framerates higher than 250. This is a experimental change, however it won't break anything.

Now framerates higher than 250 will use deprecated setImmediate (this is fine because it is polyfilled by https://www.npmjs.com/package/setimmediate) instead of setTimeout to call vm.runtime._step, allowing the engine to capture multiple DOM events before screen drawing.

The vm.runtime.renderer.draw() is now synchronized with screen refresh rate while interpolation still works.

Newly added features:

vm.runtime.screenRefreshTime

Screen refresh time speculated from screen refresh rate, in milliseconds. Indicates time passed between two screen refreshments. Based on site isolation status, the resolution could be ~0.1ms or lower.

sensing_current screen refresh time (field value refreshtime)

Indicates screen refresh time (described above) in seconds. This is required for Scratch projects to detect when to draw, for example:

(The argument reporter is replaced with sensing_current now)

If the program is running on a 60Hz monitor with 480 FPS, it will run with 90 rendering frames (to avoid sudden frame dropping) and 480 logic frames.

Reason for Changes

Consider this situation:

1. You are using a 60Hz monitor however the framerate is set to 240 (this actually makes the game smoother).

There are only 60 screen updates every second while vm.runtime.renderer.draw() is called 240 times, which means that 180 calls are unnecessary.

2. Some rhythm games require higher I/O (keyboard, mouse, etc.) sample rate for inputs.

They could do this by changing framerate, but it is impossible to set framerate (= I/O sample rate) higher than 250.

Test Coverage

N/A. This is basically browser stuff. However, all tests are passed and it works fine with pen & sprite projects.

Additional Information

It is recommended to squash merge this Pull Request.

[GarboMuffin]

haven't looked at the rest of this but we are not adding new blocks using argument reporters. "last key pressed" was a mistake that should've never happened.

[FurryR]

haven't looked at the rest of this but we are not adding new blocks using argument reporters. "last key pressed" was a mistake that should've never happened.

There's no way to detect screen refresh rate in original Scratch. And there's also no way to let an extension load in original Scratch. If we dont use argument reporters, we must find a new solution to indicate screen refresh rate so applications could work more efficiently.

[FurryR]

I hope you can reconsider this PR. I've already changed argument_reporter_string_number to sensing_current so it should not bring any historical issues.

[FurryR]

Sorry, it was a mistake.