There's various pieces of data we store (in redux) to keep track of what part of the tree we're zoomed to, what parts of the tree are visible. This got more complex after the introduction of #1993. I am reasonably certain we can simplify this a whole lot. The salient properties/objects are:
idxOfInViewRootNode (used to work out which nodeidxOfFilteredRoot (mainly used to decide whether we can zoom to selected; doesn't consider time and genotypes?)inView (boolean on each node which is a descendant of idxOfInViewRootNode, i.e. is on screen)visibility (which branches / tips are "on" / "selected" - we need a better word for this!)focusNodes.nodes & focusNodes.roots (only calculated when "focus on selected" is used)
Without fully checking edge cases (which is a lot of work!) I think:
focusNodes.nodes and visibility can be unifiedfocusNodes.roots and idxOfInViewRootNode can be unified- Filtering should be simplified and clarified by including time & genotypes
inView and visibility can be combined and sped up into a single array of bitwise flags, stored as Uint8Array(n).
Note: Separate to these data, it would be much simpler if PhyloTree could keep access to the (current) state of the redux store. This would greatly simplify the logic, and allow our change.ts files to work our which update calls to make and not have to worry about supplying the updated data as well.
All of the above can be broken down into separate issues / PRs, but together they form a coherent body of work.
There's various pieces of data we store (in redux) to keep track of what part of the tree we're zoomed to, what parts of the tree are visible. This got more complex after the introduction of #1993. I am reasonably certain we can simplify this a whole lot. The salient properties/objects are:
idxOfInViewRootNode(used to work out which nodeidxOfFilteredRoot(mainly used to decide whether we can zoom to selected; doesn't consider time and genotypes?)inView(boolean on each node which is a descendant ofidxOfInViewRootNode, i.e. is on screen)visibility(which branches / tips are "on" / "selected" - we need a better word for this!)focusNodes.nodes&focusNodes.roots(only calculated when "focus on selected" is used)Without fully checking edge cases (which is a lot of work!) I think:
focusNodes.nodesandvisibilitycan be unifiedfocusNodes.rootsandidxOfInViewRootNodecan be unifiedinViewandvisibilitycan be combined and sped up into a single array of bitwise flags, stored asUint8Array(n).Note: Separate to these data, it would be much simpler if PhyloTree could keep access to the (current) state of the redux store. This would greatly simplify the logic, and allow our
change.tsfiles to work our which update calls to make and not have to worry about supplying the updated data as well.All of the above can be broken down into separate issues / PRs, but together they form a coherent body of work.