Some tasks in Slicer are computationally intensive; an example could be running the Grow from seeds effect in the Segment Editor module.
Accidentally invoking a computationally intensive task
When dragging the Seed locality slider for this effect, Slicer is prone to initiate running of the analysis before the user has released the slider knob. (I think it is being triggered when the user momentarily pauses the dragging, albeit without releasing the mouse button.)
This should not happen. The infelicity could be ignored if the task took milliseconds to run, but when it takes dozens of seconds (and potentially minutes) to run, it causes a problem for the user.
One solution may be along the following lines:
“when the slider is pressed, I disconnect the valueChanged slot, and when the slider is released, I reconnect it and I throw a valueChanged signal”
A complication of this solution: the current implementation of the widget seems to be to (sensibly) not execute the call until the user has stopped adjusting the value: e.g. clicking several times in ‘quick’ succession on the slider’s rail only results in invocation once the series of clicks is completed (recognised as a pause in the sequence). Reconnecting a disconnected slot prematurely might degrade this behaviour.
Aborting a computationally intensive task
Another situation is where the user has genuinely changed a setting (by releasing the mouse button, or whatever) or otherwise (intentionally or accidentally) caused a computationally intensive task to be invoked.
I have not seen any way to safely abort such tasks: the only avenues I’m aware of are to wait for the task to finish, or close 3D Slicer entirely. The former is time-consuming, and will not work in the (rare) case of a bug preventing the task from finishing at all. The latter is tiresome even if all prior work was saved, and very troublesome if prior work was not saved (potentially minimised with auto-save).
Is there an abort option? If not, can one be added?
Note: the Seed locality slider setting seems to call the task regardless of whether Auto-update is ticked or not. I’m not sure that that’s the expected behaviour. But even if it isn’t, each of the above two points (in the original post) still stands.
It is no problem at all to apply seed locality when the mouse button is released (by turning off tracking property of the slider). It would be great if you could send a pull request with this change, but if you are not sure how to do it then I can get to it early next week.
Grow from seeds update should take only a few seconds. Make sure you use the latest Slicer Preview Release. The latest Stable Release had some unnecessary extra updates. Seed locality may require a full recomputation, so that may take up to a few ten seconds, but that’s not a parameter that you need to tune often, but you need to determine the good value only once for a certain task and then the same value should be usable for all patients.
Thank-you for the feedback, Andras.
It definitely was very slow; although admittedly I also had ended up with a very large number of manually painted regions, in an attempt to finesse the outcome.
Generally I had only been using the Stable Releases up until now, as the idea of using an ‘unstable’ release was off-putting. With most software I’ve encountered, regular users are mainly encouraged to use regular releases, rarely beta versions, and never alpha versions. 3D Slicer seems to be different, so, following your advice, I will try the “Preview” releases in future.
—DIV
I am not sure of how to code this.
My best guess, following your comment, is something like seedLocalityFactorSlider.tracking = 0 or seedLocalityFactorSlider.tracking = 'off' or seedLocalityFactorSlider.tracking = False…
If you are able to get to this, would you be able to somehow link to the changes you’ve made?
If we can release a new Slicer version in every quarter then you can use the latest stable. However, the stable release was delayed by due to complications with VTK update and other refactoring work in preparation for Slicer5, that’s why you are better off overall with the Slicer Preview Release in these months. If we release Slicer5 then you can get back to using the latest Slicer Stable Release.
Type of the tracking property of the ctkSliderWidget is a bool:
Therefore, the proper way to set it is to use the Python bool type (True or False). Automatic casting from integer probably works, too, so 1 and 0 may be usable, too. String values, such as "on" or "off" will not work. Add this single line where the slider is set up and see if it works as you expect. If it does then please create a pull request with that change. Thank you!