Support updates to positions of scatter3d points#559
Conversation
nvaytet
changed the title
nvaytet
changed the title
| opacity = self.opacity.value if at_least_one_cut else 1.0 | ||
| self._set_opacity({'new': opacity}) | ||
|
|
||
| if (not self._nodes) and at_least_one_cut: |
There was a problem hiding this comment.
We change the mechanism here: instead of grabbing the data from the nodes in the view, we add children nodes to the data which is the input to the view.
This means that automatically, if the input data changes, the data in the cuts will also update.
We ca now do this because updating a scatter point with different number of points is now allowed (when we update the cut range, the number of selected points changes).
|
Assigning you @jl-wynen as you already reviewed the older PR, and changes here are pretty similar (though some things were fixed with the clip3d). |
| self._canvas.remove(self.points) | ||
| self.points = new_points | ||
| self._canvas.add(self.points) |
There was a problem hiding this comment.
Could you further change this?
| self._canvas.remove(self.points) | |
| self.points = new_points | |
| self._canvas.add(self.points) | |
| self._canvas.add(self.points) | |
| self.points = new_points | |
| self._canvas.remove(self.points) |
There was a problem hiding this comment.
Not sure I get it, why would I add the current points again instead of the new points?
There was a problem hiding this comment.
Ah, I missed that self.points changes in the middle.
My idea was to add and then remove to not have a blank canvas in case that causes problems. But does 3js rerender when removing points? Or only when you explicitly tell it to?
| ].astype('float32') | ||
|
|
||
| def update(self, new_values): | ||
| def update(self, new_values: sc.DataArray) -> None: |
There was a problem hiding this comment.
Is it feasible to have a simpler update_values method that only updates the colours and that gets called by nodes that do not change positions?
There was a problem hiding this comment.
Not really, the values you get from an update are just a full data array with new data, where both coordinates or data could change.
If we want to change this, then it would be a much more fundamental change in how the whole Plopp works...
| ) | ||
| self._nodes[n.id].add_view(self._view) | ||
|
|
||
| if self._nodes and (not at_least_one_cut): |
There was a problem hiding this comment.
Why not at_least_one_cut here? Don't you want to remove old nodes regardless of whether there is a cut now?
There was a problem hiding this comment.
So the logic is the following:
To start with, we have just the original data nodes (just say one of them for simplicity, which is the most common case).
When a button is clicked to create a new cut, we add a node which selects a subset of data points from the original node.
After that, no matter how many new cuts we add on top, we are still using that same node, which performs a selection from the originaly node, combining all selection criteria from the different cuts. There are at most only 2 nodes in play at any time: the original node and the node that does the selection.
Once the last cut gets deleted, that is when we need to remove the additional ('selection') node.
So this needs to happen when the final cut has been deleted.
Does that make sense?
There was a problem hiding this comment.
I added the explanation as a comment in the code
Co-authored-by: Jan-Lukas Wynen <j-l.wynen@hotmail.de>
2 participants
Alternative to #484
Much of the changes are similar, but things are written in a simpler manner here, and we do not check for equality of coordinates (as this took time).
Updating the positions is between 3 and 10 times faster than updating the colors.
The gain of removing the unexpected behaviour that positions don't update (only colors used to update) are worth the cost, I think.
I tried looking at the Dream instrument view again and the loss of performance was not noticeable, contrary to what I wrote in #484 (comment)
Possibly because of performance updates done on the instrument view side itself? (scipp/scippneutron#691)
Fixes #495