In the current design, each device contains rendering objects (jit.gl.mesh jit.gl.text) and physics interaction objects (jit.phys.body) as well as a considerable amount of duplicated logic for handling interactions. As a result, each device's memory footprint is relatively large. This leads to a memory bottleneck and limits the quantity of devices that can be included in a session before performance drops off drasticaly: see #129, #130.
Possible refactoring approaches include:
- Object pooling: use JavaScript to spawn a fixed quantity of
jit.gl.mesh, jit.gl.text and jit.phys.body objects. When a given symbol moves into the visible range of the score, dynamically allocate the objects needed to draw that symbol. This would mean that the you only need to spawn enough of these objects to account for all of the symbols that appear in the viewport at any given time, rather than paying for one object per symbol whether it's visible or not.
- Device minimization: devices should only host UI objects, which are required in order to store automation. All other logic should be centralized in SIGNe-Screen and passed back and forth as needed via
send and receive objects.
- Static objects: create a device that can store data for multiple objects in a dictionary. These objects cannot be animated (due to the lack of statically created parameters), but this approach should have a considerably smaller memory footprint than creating one device per object.
In the current design, each device contains rendering objects (
jit.gl.meshjit.gl.text) and physics interaction objects (jit.phys.body) as well as a considerable amount of duplicated logic for handling interactions. As a result, each device's memory footprint is relatively large. This leads to a memory bottleneck and limits the quantity of devices that can be included in a session before performance drops off drasticaly: see #129, #130.Possible refactoring approaches include:
jit.gl.mesh,jit.gl.textandjit.phys.bodyobjects. When a given symbol moves into the visible range of the score, dynamically allocate the objects needed to draw that symbol. This would mean that the you only need to spawn enough of these objects to account for all of the symbols that appear in the viewport at any given time, rather than paying for one object per symbol whether it's visible or not.sendandreceiveobjects.