Ticket #740 (closed defect: fixed)

Opened 8 years ago

Last modified 7 years ago

Stack to Images slow

Reported by: bdezonia Owned by: bdezonia
Priority: major Milestone: imagej2-b2-bugfixes
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 8 years ago by bdezonia

  • Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2

comment:2 Changed 8 years ago by curtis

  • Blocking 1011 added

comment:3 Changed 7 years ago 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 7 years ago by bdezonia

Also fails on Mac. It looks like LegacyPlugin::run() is stuck in waitForPluginThreads()

comment:5 Changed 7 years ago 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 7 years ago 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 7 years ago 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 7 years ago by bdezonia

  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta2

comment:9 Changed 7 years ago 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.

Note: See TracTickets for help on using tickets.