Ticket #1404 (closed defect: fixed)
Opened 2012-08-14T14:51:57-05:00
Last modified 2012-12-12T13:13:56-06:00
Display tracking problems exist when running legacy code from within IJ2
| Reported by: | bdezonia | Owned by: | bdezonia |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | Legacy Compatibility | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1584 |
Description (last modified by bdezonia)
Here is some IJ1 code that can cause issues (documented below):
ImagePlus imp1 = IJ.openImage(" http://imagej.nih.gov/ij/images/blobs.gif");
imp1.show();
ImagePlus imp2 = IJ.openImage(" http://imagej.nih.gov/ij/images/boats.gif");
imp2.show();
ImagePlus imp = IJ.getImage();
IJ.selectWindow("blobs.gif");
ImagePlus imp3 = IJ.getImage();
ImageProcessor ip=imp3.getProcessor();
imp3.hide();
If this code is part of a legacy plugin that is discovered and loaded into the menus it (I believe) works fine and only the boats image is left open.
If this code is part of a legacy plugin that is run via Compile and Run the blobs image also stays open (incorrect). This is because the LegacyOutputTracker puts opened/closed images into thread local sets and since Compile and Run launches another thread to run the user specified plugin there are two different sets of output/closed ImagePluses and the tracking is lost.
FInally if this code is placed into an IJ2 plugin directly it behaves like the Compile and Run case. But here there is no initialization and cleanup of output/closed ImagePluses since that is part of LegacyPlugin::run() and the IJ2 plugin is decidedly not a LegacyPlugin. We should not record opened/closed info in legacy layer when code has not been invoked from within LegacyPlugin. Or we should always track ImagePlus info and even IJ2 plugins should deal with open/close/harmonize. Not great.
(Note that the problems inherent in using IJ1 code in an IJ2 plugin should inform the tutorial on how to port a plugin)
Change History
comment:3 Changed 2012-08-14T15:46:13-05:00 by bdezonia
Note that with commit ef1b45b86586c57c7ee6d55b35b7b98949d8716d the closing behavior is improved here. Now Windows always close correctly. However the design of the legacy layer will not support the use of legacy IJ1 code in an IJ2 plugin. All code must go through LegacyPlugin::run() to be handled correctly. And all the thread local issues still exist for things like output ImagePluses during Compile and Run. Look into this issue more carefully.
comment:4 Changed 2012-09-04T15:15:48-05:00 by bdezonia
General thought: our code hacker implementation could capture the current Thread's ThreadGroup and register ImagePluses to that. Then we can avoid thread locals and bad references. And we could maybe name the ThreadGroup distinctively so that we can tell if it's from IJ1 or IJ2. Then not record anything for IJ2 threads.
comment:5 Changed 2012-09-07T11:18:41-05:00 by bdezonia
- Blocking 1459 added; 1331 removed
- Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta5
comment:6 Changed 2012-12-12T13:12:33-06:00 by bdezonia
- Status changed from new to closed
- Resolution set to fixed
- Milestone changed from imagej2-b7-ndim-data to imagej2-b6-legacy-undo
With commit 91a61bda316343d9c7f9a59baeb7b3f022d03c3b the code hacking methods were modified to only update the legacy tracking variables when the parent thread is one derived from LegacyCommand. This allows any IJ2 plugin (that is dependent on ij-legacy) to use IJ1 structures if desired without unexpected side effects. Some IJ1 methods will do nothing (specifically the display oriented and closing oriented methods). But there is now no longer any confusion in the legacy output tracking.
Note that the issue with Compile And Run hatching its own threads is still present. I will open that up as a separate ticket. Closing this one.