NOTICE! This is a static HTML version of a legacy ImageJ Trac ticket.

The ImageJ project now uses GitHub Issues for issue tracking.

Please file all new issues there.

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: imagej2-b2-bugfixes
Component: Legacy Compatibility Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking: #1011


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:2 Changed 2012-02-26T20:55:10-06:00 by curtis

  • Blocking 1011 added

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


at ij.gui.ImageWindow.close(
at ij.gui.StackWindow.close(
at ij.plugin.StackEditor.convertStackToImages(
at ij.IJ.runPlugIn(
at ij.IJ.runPlugIn(
at java.util.concurrent.FutureTask$Sync.innerRun(
at java.util.concurrent.ThreadPoolExecutor.runWorker(
at java.util.concurrent.ThreadPoolExecutor$

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.