When calling `Engine.RunGuiPage` a promise is returned. The promise is fulfilled when the "child" page is closed. That allows to `await` it inside `async` functions.
Previously the callback is run right inside the call to `Engine.PopGuiPage`. Now the continuation of the promise is called at the end of the "tick".
This diff won't help performance. It will morelikely make things worse. Since gui pages aren't opened or closed that frequently, it doesn't matter that much.
For the engine side:
The promise is stored in the `CGUIManager::SGUIPage` (like previously the callback). When the promise is fulfilled it enqueues a callback in the `JobQueue` of the `JSContext`. Our `JobQueue` only forwards the callback to a job-queue owned by the `ScriptInterface` so that we get controll when which `ScriptInterface` calls it's jobs.
The jobs of the topmost gui page are called at the end of every tick.
The jobs of the other `ScriptInterfaces` aren't called. (TODO: fail when trying to use promises in such `ScriptInterfaces`)
Future work:
- Allow the child-page to return a promise instead of calling `Engine.PopGugPage`.
- It would be nice to be able to run JS work in a thread manner, but that's more work.
Design questions:
- Is it a good idea to support asynchronous calls from Javascript? It might well lead to unpredictable lag.
- If so, when and where?