we want only the renderers, and the class method abstractions, in the UI thread. What I mean by class method abstractions is that, suppose a user wants to build a scene graph. The user can do the following in the UI thread:
var node = new Node()
node.addComponents(DOMElement)
node.addChild(new Node())
// etc ...
and those APIs that are always available in the UI thread have interfaces that, behind the scenes, delegate to instances that are inside workers. The user shouldn’t have to worry about actually placing their code into a worker. Method calls in the UI thread would be like RPC (similar to Meteor methods where the user can call server-side methods from the client). Behind the scenes, messages from UI-side method calls are sent to corresponding instances that live in workers; instances created when the user does new Node in the UI thread, etc. This could, in theory, also work with network-based RPC with little modification (only the messaging layer needs to be changed).
The UI-side API would be “smart”: If you call node.setPosition on the UI-side, it delegates to the worker-side Node instance where (perhaps) the whole scene graph is located, which eventually updates the UI-side renderer via messages. If you call domElement.getElement on the UI-side, this gets you the element on the UI-side, and there’s no need for a message to be sent to a worker in that case (but the user doesn’t know this, the user only uses the public API and gets a DOM element as expected).
This would all happen transparently, and the user wouldn’t know what actually executes in a worker or not. Integrating with Meteor Blaze (or React/Angular/etc) would be easy because our “smart” API would make it easy:
// some code in some Meteor app:
domElement.getElement(function(element) {
Blaze.renderWithData(Template.myTemplate, data, element)
})
If the users calls sizeComponent.set(...) then that sends a message into a worker (probably the one where the scene graph lives). So, the API would basically be ‘smart’ (knowing what to send into workers), and the entire public API would always be available on the UI thread for simplicity and ease of use.
We don’t have to avoid direct DOM access. That part of the API (behind the scenes) wouldn’t send messages into a worker.
how would we handle these kinds of dependencies if we’re sending messages to worker threads
Hope I kind of answered that question. Those integrations would use the public API, and would not need to know about our engine’s workers.
Any thoughts on that?