As documented in an issue against the spikesortingview project, the mechanism for syncing other views' focus time with the time implied by the current animation frame is fairly complex. It works okay, but a conceptually simpler model would be better for both code comprehension and (hopefully) efficiency.
Theoretically, it should be possible to do a version of this that creates a single callback which doesn't need to be updated very often. This callback would take the animation state and the focus time (received from the RecordingSelectionContext) and would be called in a useEffect hook in the track animation view.
The callback would check if the focus time and the current frame time are far enough apart to require an update. If so, it would identify which of the two sources of time had updated more recently, and then sync the other one to match.
Some work has been done on this on the simplified-time-syncing branch though it still requires further development and debugging. (For instance, there is some rollback when state update instructions are issued rapidly, probably due to lagging state changes the refresh to an old state). It might benefit from a throttling mechanism; or it's possible that I'm still making incorrect assumptions about the order in which things are resolving...?
In any event, this is not sufficiently high priority to continue developing right now, but I should get back to it at some point.
As documented in an issue against the spikesortingview project, the mechanism for syncing other views' focus time with the time implied by the current animation frame is fairly complex. It works okay, but a conceptually simpler model would be better for both code comprehension and (hopefully) efficiency.
Theoretically, it should be possible to do a version of this that creates a single callback which doesn't need to be updated very often. This callback would take the animation state and the focus time (received from the
RecordingSelectionContext) and would be called in auseEffecthook in the track animation view.The callback would check if the focus time and the current frame time are far enough apart to require an update. If so, it would identify which of the two sources of time had updated more recently, and then sync the other one to match.
Some work has been done on this on the simplified-time-syncing branch though it still requires further development and debugging. (For instance, there is some rollback when state update instructions are issued rapidly, probably due to lagging state changes the refresh to an old state). It might benefit from a throttling mechanism; or it's possible that I'm still making incorrect assumptions about the order in which things are resolving...?
In any event, this is not sufficiently high priority to continue developing right now, but I should get back to it at some point.