Improve SKNode marshalling
mchakravarty opened this issue · comments
Manuel M T Chakravarty commented
Consider this alternative scheme (and adapt the todo items below):
- The
SKNode
representation keeps a stable pointer to the Haskell representation it originates from. (Then, we can probably get rid of the special case of how we are doing that for scene nodes right now and we don't need to have the"haskellUserData"
entry inSKNode
suserData
as this is subsumed bu a reference to the entire Haskell representation.) - We update the Haskell representation each time we marshal the node back from
SKNode
to Haskell. - When merging a (possibly) updated Haskell representation into the foreign
SKNode
representation, we always determine the to be updated delta by comparing to the Haskell representation refereed to be theSKNode
(that crucial depends on the previous point). - When we call back into Haskell in scene update functions or custom actions, we have no idea which part of the referenced Haskell representation (except the user data) is still valid and so need to create a new Haskell representation from scratch. However, when we need to marshal the Haskell representation to an
SKNode
to invoke methods, such asframe
orcalculateAccumulatedFrame
(assumingnodeForeign
is set), we update the reference to the Haskell representation, which then serves as the delta for the next Haskell toSKNode
marshalling — saving work when we call multiple functions, such asframe
or when the Haskell representation is passed back unchanged as a result node.
One big advantage of this scheme is that reordered lists of children don't take any effort to match the old and new Haskell representations that need to be compared. - The current implementation of
addChildren
is quite inefficient for large arrays of children. We should use sets for the containment testing when the arrays get bigger. - The current implementation of
addChildren
doesn't generally preserve the order of the children (wrt to the order in the Haskell structure). This is bad as the drawing order depends on the order of the children. - Improve
Node.addChildren
and related functions. When we update an existingSKNode
tree with Haskell-side changes, currently, the whole tree gets traversed if thenodeChildren
field of the root changed at all. This is quite inefficient on large trees. It would be better, while inspecting the individual children to see whether some children didn't change at all and then prune the traversal using that information.