Hanging popup some times after loading DICOM files

Development
1

Sometimes after loading som DICOM files, the popup window showing the text “Processing…” doesn’t disappear unless I close it manually. I don’t know why it happens, and it doesn’t happen every time. Usually it just disppears almost immediately after it appears. But when I look at many different DICOM files in a row, it inevitably happens after a while. I use CRTL+w to close each scene and then go to the DICOM browser to select a different entry in the DICOM browser, click on “Examine” and then “Load”.

The problem is not tied to any specific DICOM files. I’m not able to reproduce it reliably.

Here is a screenshot showing the hanging popup window:

slicer3d_processing_popup
slicer3d_processing_popup1500×1004 47 KB

Best regards,
Torquil Sørensen

2

You might have found something related to the issue discussed at https://github.com/Slicer/Slicer/pull/951.

Which Slicer version are you using?

3

I’m using Slicer 3D nightly version 4.11.0-2019-03-03 r27973 on Linux. I think the problem has occured on all the Slicer versions I have used for several months. I have only used the nightly builds.

4

I have noticed this problem as well in all versions of Slicer I have tried, including a recent preview release. For whatever reason, it happens reliably when I am using Slicer with Xpra (both HTML5 and Python client). I believe I have traced the issue to this spot in the code not reliably working:

This occurs in the workflow where a QProgressDialog has already been opened and closed immediately prior.

I also noticed that if I manually expand the popup, there appears to be a lot of artifacts from prior windows all around the area that was previously visible when it was smaller.

I don’t have much experience with Qt, but I do not see anything obviously wrong with the use of the QProgressDialog. It is a minor issue but if anyone has ideas I would appreciate it.

5

Just noting that adding

progressDialog.setParent(None)

before

progressDialog.close()

seems to resolve the issue, but I am not clear why.

6

That sounds harmless so if it works, why not add it. Do you want to put in a PR?

7

Sure, I can do that. I do a little more testing first.

8

Upon further testing, adding the line:

progressDialog.deleteLater()

after

progressDialog.close()

also solves the problem. Doing both deleteLater() and setParent(None) together also works. I am not sure if one or the other, or both makes more sense. Happy to open a PR though. Unless someone with more understanding in the QT widget lifecycle has input, I would put both into the PR.

9

I’m not sure either. I’ve only seen this on linux, so maybe it’s just a corner case. As long as one of the approach works we should probably just go ahead with whatever works and seems least intrusive.