View Issue Details

IDProjectCategoryView StatusLast Update
0002794Slicer4Core: Base Codepublic2014-05-12 23:32
ReporterpieperAssigned Tojcfr 
PrioritynormalSeverityfeatureReproducibilityhave not tried
Status acknowledgedResolutionopen 
Product Version 
Target VersionFixed in Version 
Summary0002794: fast startup slice viewer
Description

Some users (Andrey, Jayashree) mentioned that they tend to use software other than slicer when they want to quickly review images because slice takes so long to start up.

It would be great to have a minimal slicer configuration that can load and display images passed on the command line.

The same tool could optionally also launch the full slicer application in the background and then switch over to it when it has been loaded.

TagsRSNA2012

Activities

pieper

pieper

2012-11-30 13:04

administrator   ~0007396

I started looking at this and did a quick test.

I found that if I enable the ctkSimplePython shell in the ctk build and then launch it with a simple startup script I can get an image display in about 3 seconds (includes time to import vtk, slicer, qt into python, plus loading the volume).

But if I bring up slicer on the same machine it takes about 15 seconds, not including time to load volume.

This test was done on a mac mini with a debug build of slicer.

Command line:

% ./Slicer-build/Slicer --launcher-no-splash --launch CTK-build/CTK-build/bin/ctkSimplePythonShell ~/Dropbox/hacks/slicer/slite.py

Contents of slite.py

print('start')
modules = ('os', 'sys', 'vtk', 'qt', 'slicer','vtkSlicerVolumesModuleLogic')

for m in modules:
exec('import %s' % m)
print('imported %s' % m)

mrmlScene = slicer.vtkMRMLScene()
appLogic = slicer.vtkSlicerApplicationLogic()
sliceWidget = slicer.qMRMLSliceWidget()

volumesLogic = vtkSlicerVolumesModuleLogic.vtkSlicerVolumesLogic()
volumesLogic.SetMRMLScene(mrmlScene)
volumesLogic.AddArchetypeScalarVolume('/Users/pieper/data/MR-head.nrrd', 'MR-head', 0, None)

sliceWidget.setMRMLScene(mrmlScene)
sliceWidget.show()

pieper

pieper

2013-03-27 04:18

administrator   ~0008247

Here's an experimental branch to move module loading out of the 'splash screen' phase of the start up process:

https://github.com/pieper/Slicer/commits/defer-module-loading

This works, in the sense that the GUI appears quickly. But then as expected it freezes while the module discovery process goes on.

What needs to happen next is to move the module discovery into threads.

Care will need to be taken on several fronts:

  • the module discovery in the threads must not trigger non-thread-safe code in the main thread (i.e. no Rendering or GUI updates)

  • the command line options to load data are the key elements that should be sped up by this process, so we need to be sure volume loading and display can happen before module discovery completes. This should be fine, since reading is handled at the MRML level and the Volumes module is not required. The IO code needs to be checked to confirm that this works.

  • Running CLI modules should be easy to do in a thread. For shared libraries I haven't found any documentation or other reason to believe that loading a shared library in a thread would be problematic - the loaded entry points should become available to the main thread. This needs to be confirmed on all platforms.

  • We should provide a property (or signal) on the main application instance indicating that the loading has completed. This way python scripts passed on the command line can be triggered after the module loading is completed. This will be important for things like python ctests where the operation is defined as a command line argument to slicer.
jcfr

jcfr

2013-03-27 07:17

administrator   ~0008250

Excellent.

Is this something you plan on completing ? A prototype implementation to get a better understanding about the pros and cons of the approach ?

pieper

pieper

2013-03-27 09:41

administrator   ~0008251

I might work on it now and then as time permits -- I tend to get motivated for it while waiting for slicer to startup :P

But I wanted to put this into the bug report so that if someone else can spend some time on it (perhaps as part of the end-of-year work for NAC) they will have some idea where to start. The nice thing about this project is that a programmer could work on it without really needing to know much about medical imaging or about how slicer works in general.

jcfr

jcfr

2013-03-27 15:02

administrator   ~0008255

Make sens. Yeapp it is indeed a fun topic to tackle :)

Issue History

Date Modified Username Field Change
2012-11-28 04:21 pieper New Issue
2012-11-28 04:21 pieper Status new => assigned
2012-11-28 04:21 pieper Assigned To => jcfr
2012-11-30 12:52 jcfr Category RSNA2012 => Base Code
2012-11-30 12:52 jcfr Target Version => Slicer 4.4.0
2012-11-30 12:53 jcfr Tag Attached: RSNA2012
2012-11-30 13:04 pieper Note Added: 0007396
2013-03-27 04:18 pieper Note Added: 0008247
2013-03-27 07:17 jcfr Note Added: 0008250
2013-03-27 09:41 pieper Note Added: 0008251
2013-03-27 15:02 jcfr Note Added: 0008255
2014-05-12 23:32 jcfr Status assigned => acknowledged
2014-05-12 23:32 jcfr Target Version Slicer 4.4.0 =>