Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve SKNode marshalling #6

Open
3 tasks
mchakravarty opened this issue Sep 2, 2016 · 0 comments
Open
3 tasks

Improve SKNode marshalling #6

mchakravarty opened this issue Sep 2, 2016 · 0 comments

Comments

@mchakravarty
Copy link
Owner

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 in SKNodes userData 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 the SKNode (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 as frame or calculateAccumulatedFrame (assuming nodeForeign is set), we update the reference to the Haskell representation, which then serves as the delta for the next Haskell to SKNode marshalling — saving work when we call multiple functions, such as frame 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 existing SKNode tree with Haskell-side changes, currently, the whole tree gets traversed if the nodeChildren 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.
@mchakravarty mchakravarty changed the title SpriteKit: Improve SKNode marshalling Improve SKNode marshalling Sep 2, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant