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?