Kethku commented 5 years ago

I've been noticing this as well. Also if you write code which takes a LONG time, the whole app freezes and takes a while to recover. I'm not sure what the best way to fix this would be though.

gabrielflorit commented 5 years ago

The first part should be easy. Right now I'm measuring FPS by how often the rAF gets fired. Instead I should measure elapsed delta in draw.

The second part... I'm afraid that sounds hard.

Kethku commented 5 years ago

Ideas that come to mind:

Run user code in a background worker. This would require changing all of the api functions to send messages which get processed instead of accessing the canvas etc directly. Some work would also be needed to cause them to take a realistic amount of time and or wait until a response is sent.
Modify api functions to pump the ui every time they are called. This doesn't really fix it since non api calling code can still halt. But it might be a good intermediate solution.
Use an interpreter instead of javascript directly. This is probably the "right" way to fix the problem. By using an interpreter, there would be much better control over execution of the code and would allow you to stop executing midway. I'm not aware of a javascript interpreter written in javascript (although I'm sure it exists), but I know of some languages which have javascript interpreters including lua. This would also make it much harder to escape the sandbox via strategies like https://github.com/script-8/script-8.github.io/issues/193

Any thoughts on any of these?

gabrielflorit commented 5 years ago

1 is potentially doable, but I can see timing getting finicky, because if I understand correctly, background workers are async.

3 is most interesting. So you're saying the user would write lua, then I compile to JS, and the browser runs JS?

Kethku commented 5 years ago

I think maybe more like use a lua (or other, see below) interpreter written in javascript to run the user's code. By interpreting the code instead of compiling it, we can more exactly control what the code has access to, and can stop it at any time.

The current version's use of eval (I think, maybe its a script tag? Haven't dug in) means that everything has to wait until the executed javascript is finished. The interpreter doesn't have this problem since we would be able to pump the execution ourselves. Something like while (timeLeft != 0) { interpreter.pump() }

The interpreter doesn't have to be for lua either, I just know there were other people wanting it. I've seen javascript interpreters written in javascript such as https://github.com/jterrace/js.js/ or https://github.com/NeilFraser/JS-Interpreter which have varying support for es6 features. Or even toy scripts which could work as well. The key point is giving the engine a way to pump the user code manually instead of just running it in the browser as plain old javascript.

Kethku commented 5 years ago

As an added benefit, a system like this would allow us to artificially control how much time each api call takes. Pico8 has a similar system to constrain how much code is allowed to run. I'd imagine the current system in SCRIPT-8 could be abused to create 3d graphics etc that runs quickly just because Javascript is incredibly fast these days. An interpreter would slow things down somewhat but also let us slow down certain commands manually in a clean way.

gabrielflorit commented 5 years ago

This is all quite interesting! I had no idea people wrote JS interpreters in JS. I will have to read up on this.

The artificial constraints aren't something that's a top priority for me. The way I see it, if you really want to, there's nothing stopping you from making this run webgl. So if one really wants to, ... go ahead! But I suspect they'd better served by dropping the script-8 constraints at that point.

Kethku commented 5 years ago

That makes sense to me! I was just pointing out another potential benefit :) The nice bit about this architecture as well is that if done carefully, plugging in other interpreters could be pretty easy. I could imagine a situation where javascript is an option, but you could also run lua or some version of lisp just as easily.

colxi commented 5 years ago

Run user code in a background worker. This would require changing all of the api functions to send messages which get processed instead of accessing the canvas etc directly. Some work would also be needed to cause them to take a realistic amount of time and or wait until a response is sent.

OffscreenCanvas is a cool solution for sync access to a canvas context , from the Worker context

Is already available in Chrome, where works like a charm, and partially in Firefox. It should arrive to all browsers sooner or later. https://developer.mozilla.org/en-US/docs/Web/API/OffscreenCanvas

gabrielflorit commented 5 years ago

Oooh looking

gabrielflorit / script-8.github.io

The FPS counter doesn't seem accurate #195

1 is potentially doable, but I can see timing getting finicky, because if I understand correctly, background workers are async.

3 is most interesting. So you're saying the user would write lua, then I compile to JS, and the browser runs JS?