Ticket #740 (closed defect: fixed)
Opened 2011-09-06T12:11:43-05:00
Last modified 2012-05-16T14:47:36-05:00
Stack to Images slow
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | Legacy Compatibility | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1011 |
Description
The stack to images IJ1 command can run slowly. Determine if its too slow and needs to be fixed. If fixes needed track through the legacy layer and make improvements where possible.
Change History
comment:1 Changed 2011-09-21T15:00:46-05:00 by bdezonia
- Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2
comment:3 Changed 2012-05-08T10:49:04-05:00 by bdezonia
Seems a lot faster nowadays (tested with a five slice stack on Linux)
However, using new HyperStack create a 1 ch, 1 frame, 15 slice stack. Run Stack To Images and nothing happens. Run it again and you get an exception
java.lang.NullPointerException
at ij.gui.ImageWindow.close(ImageWindow.java:343)
at ij.gui.StackWindow.close(StackWindow.java:169)
at ij.plugin.StackEditor.convertStackToImages(StackEditor.java:268)
at ij.plugin.StackEditor.run(StackEditor.java:27)
at ij.IJ.runPlugIn(IJ.java:156)
at ij.IJ.runPlugIn(IJ.java:139)
at imagej.legacy.plugin.LegacyPlugin.run(LegacyPlugin.java:146)
at imagej.ext.plugin.PluginModule.run(PluginModule.java:151)
at imagej.ext.module.ModuleRunner.run(ModuleRunner.java:150)
at imagej.ext.module.ModuleRunner.call(ModuleRunner.java:120)
at imagej.ext.module.ModuleRunner.call(ModuleRunner.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:679)
comment:4 Changed 2012-05-08T12:31:31-05:00 by bdezonia
Also fails on Mac. It looks like LegacyPlugin::run() is stuck in waitForPluginThreads()
comment:5 Changed 2012-05-08T13:05:18-05:00 by bdezonia
With a62a04f3d598487b08b1f1c0f1e794a1a54a6b5b waitForPlugThreads() should no longer hang.
Note that this command now completes but takes a LONG time with no updates to UI. One could think the command did not run. IJ1 does not update the status area when it runs so we have nothing to display.
comment:6 Changed 2012-05-08T13:58:07-05:00 by bdezonia
With 83e1cad8c114c9b3d1276710ecf7e83a406800a7 update users via status events that IJ2 is running an IJ1 plugin. This lets the user know their command was launched and is helpful info when a legacy plugin takes a while to complete.
TODO - determine why Stack To Images with 15 slices is so much slower than IJ1
comment:7 Changed 2012-05-09T12:40:54-05:00 by bdezonia
After a little investigation it appears the pauses are due to two things
- it looks like JHotDraw is trying to load images across the network when a display is created
- SwingUI::onDisplayCreated() is eating the lion's share of the time calling createMenuBars
Addressing part two is hatched as part of ticket #1160
The remaining work on this ticket is to determine what JHotDraw is doing.
comment:8 Changed 2012-05-14T10:13:39-05:00 by bdezonia
- Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta2
comment:9 Changed 2012-05-16T14:47:36-05:00 by bdezonia
- Status changed from new to closed
- Resolution set to fixed
Debugging into JHotDraw it seems that nothing is taking extra time. Image Fetcher threads do get hatched and don't go away but I think those are left over from the IJ1 plugin. When I interrupt the program while the slow refresh state is happening I am inside menu creation code and related state setting code. Breakpointing everything that could create an Image Fetcher shows they aren't hatched by JHotDraw. I think this bug is all menu creation time and thus I am closing this ticket.