BUG: Render 3D view quickly when SH folder visibility is toggled #8058
Conversation
c10c16e to
ff880bc
Compare
|
Now that the stable is out and PW is over, I'd like to propose this PR for integration. Thanks a lot! |
|
@lassoan What do you think? Is this a reasonable change? It fixes a real issue, although does not remove the workaround. |
|
@lassoan Can you please give this a quick look? Thanks! |
|
If there is an update issue then we should be able to address it by adding the missing RequestRender calls (and not with decreasing batch processing probability). Do your have a simple way to reproduce this update issue? Have you measured computation time vs. number of items to update; with/without batch processing? I think the breakeven point is way below 50 items, but we should really measure it. The best would be to have a Python script that creates nodes and shows/hides them and reports the time it took with and without batch processing. If needed then the logic of counting items can be tuned (e.g., exclude folders), but usually a folder contains at least 5-10 nodes, so excluding folders (or other rare item types that are not displayable nodes) should not make a huge difference. |
|
Thanks for the review! I don't think I'll have time to do this analysis, so maybe I'll just make a fork for this simple change. Can the commit that fixes the crash be integrated? |
|
I've moved out the fix of the crash to #8701, as it does not require any further discussion or testing. About the folder visibility: I've made some fixes a few days ago that may fix the folder visibility issues that you encountered. @cpinter could you test if you can still reproduce issues with the latest Slicer Preview Release? (if not, then the changes in the second commit of this pull request might not be needed anymore) |
ff880bc to
9fd9f34
Compare
There has been a threshold in the Subject Hierarchy tree view for the number of children in a folder, above which setting the visibility was done in batch processing state. If batch processing is used, the visibility change is not reflected in the 3D view until rendering is requested (e.g. rotating view). Also, setting the visibility takes about twice as long. Batch processing makes sense if there are a lot of nodes, but the current threshold (10) seems too low to make up for this gain (it even slows it down as mentioned). Also, this threshold takes into account the total number of children, not just the displayable ones (there may be tables etc.), so its usefulness is limited. This commit increases the threshold to 50 fix the visibility bug, but apparently it also makes it faster. It will be necessary to revise having 0this threshold, and to fix the root cause of the visibility bug (apparently processEvents and RequestRender calls do not help). The bug is reliably reproducible by loading the RANDO^ENT patient from the SlicerRT test data (need to have SlicerRT built/installed), and trying to toggle plan visibility. The beams disappear from the 2D views, but not from the 3D views until there is user interaction. This is part of the work to improve RT plan features, see SlicerRt/SlicerRT@169518a
9fd9f34 to
8a8b074
Compare
Sorry, again, I missed a comment. I'll do this in the next days. Thanks! |
Two small fixes in SH related to recent SlicerRT improvements and investigation.
No need to handle this until after the stable release.
Note
Changes originally integrated through this pull request have been extracted and contributed as independent pull request(s):