View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0002015 | Slicer4 | Module DICOM | public | 2012-05-10 16:53 | 2013-07-08 07:15 |
Reporter | inorton | Assigned To | pieper | ||
Priority | high | Severity | minor | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | |||||
Target Version | Slicer 4.3.0 | Fixed in Version | Slicer 4.3.0 | ||
Summary | 0002015: Checking DICOMSlicerDataBundlePlugin and ""ScalarVolumePlugin every time | ||||
Description | When I click on a study or image, these messages always pop up.. | ||||
Tags | No tags attached. | ||||
Bump. Unfortunately it seems like some fix - maybe for the other bug - has made this worse, acutely so since the 7/16 nightly. In the 7/16 nightly, after clicking + to expand the study group the message is only displayed for about 15 seconds. In the 7/18 nightly, the first time I click on a study after importing it takes {timed trials: 1:40, and 2:00} to get beyond this "Checking *Plugin" popup. |
|
I am comparing clicking on the same studies in both versions, using separate database folders and empty databases. One of the studies (1:40) has 6 image series with <300 images total. The other (2:00) has one image series with about 400 images. |
|
Yes, I'm acutely aware and working on it now :/ Seems that the ctkDICOMModel keeps open a connection to the sqlite database, so anything that tries to write into it hangs for a long time, which happens while caching tags (which was supposed to be a speedup trick). I think the best fix now will be to use a different sqlite file for the tag cache, rather than a different table in the same database. This will help us keep an eye on the size also. |
|
This commit should help. I see another use case or two that can be improved, but I hope this gets the bulk of it. commit 36784c5d1b94052a7f8859c25b027b80ae708af4 |
|
Would it be possible to provide Steve with some feedback. If no feedback is given by Friday afternoon or if the problem persists, the issue will be re-targeted for 4.3. |
|
See 0002016: slowness persists. |
|
Please re-target. |
|
Ron and I reviewed the options and came up with a plan to make the plug-in evaluation happen only when the user requests it, rather than on each click in the patient/study/series tree. Longer term I would like to find a way for the plug-in evaluation to go on in the background after an import or something similar. |
|
Can you consider only checking for scalar volume loader? I think it would be preferable to give a list of available loaders and do all other checks by request. |
|
Hi Isaiah - Ideally the plugins should be fast enough now that they don't get in the way -- they still bring up a dialog but it shouldn't last more than a few seconds. This was super slow before, but since the TagCache was added to CTK things have gotten much better (IMO). Or do you still find the process too slow? If so, I am thinking of a little 'Plugin Selection' button on the dicom panel that brings up a dialog with check buttons for each registered plugin. Then these would be saved in the settings for future use. Let me know what you think, |
|
I also observed this, I was demo-ing the DICOM module to some folks .. and noticed that it run the plugin each time I clicked on a row. Would it make sens to cache result ? |
|
The result is currently cached during a run so that if the same series is re-visited the same results will be used, which should be very fast. Did you observe anything that took more than one or two seconds? |
|
It was indeed in the order of one or two seconds each time. It could also probably make sens to trigger the process in a thread. Then, if the user click on an other item in the list. It abort the process associated item and focus on the current one. To keep the ui responsive and process data where the user focused. |
|
I'm closing this since the original issue is solved. If people still think the process needs to be sped up we can create a new feature request issue. |
|
Date Modified | Username | Field | Change |
---|---|---|---|
2012-05-10 16:53 | inorton | New Issue | |
2012-05-10 16:53 | inorton | Status | new => assigned |
2012-05-10 16:53 | inorton | Assigned To | => pieper |
2012-05-18 06:27 | pieper | Target Version | => Slicer 4.2.0 AHM Summer 2012 |
2012-07-19 06:20 | inorton | Note Added: 0005198 | |
2012-07-19 06:22 | inorton | Note Added: 0005199 | |
2012-07-19 06:30 | pieper | Note Added: 0005200 | |
2012-07-19 08:27 | pieper | Note Added: 0005201 | |
2012-07-19 08:27 | pieper | Status | assigned => feedback |
2012-10-25 14:21 | jcfr | Note Added: 0006788 | |
2012-10-25 14:25 | inorton | Note Added: 0006791 | |
2012-10-25 14:25 | inorton | Note Added: 0006792 | |
2012-10-25 14:26 | jcfr | Target Version | Slicer 4.2.0 - coming release => Slicer 4.3.0 |
2012-12-06 05:05 | pieper | Note Added: 0007421 | |
2013-02-26 13:28 | inorton | Note Added: 0008056 | |
2013-02-26 13:50 | jcfr | Priority | normal => high |
2013-02-28 11:55 | pieper | Note Added: 0008073 | |
2013-02-28 12:30 | jcfr | Note Added: 0008074 | |
2013-02-28 12:46 | pieper | Note Added: 0008075 | |
2013-02-28 12:52 | jcfr | Note Added: 0008080 | |
2013-02-28 12:53 | jcfr | Note Edited: 0008080 | |
2013-07-08 07:15 | pieper | Note Added: 0008882 | |
2013-07-08 07:15 | pieper | Status | feedback => closed |
2013-07-08 07:15 | pieper | Resolution | open => fixed |
2013-07-08 07:15 | pieper | Fixed in Version | => Slicer 4.3.0 |