Ticket #647 (closed defect: wontfix)

Opened 8 years ago

Last modified 7 years ago

IJ1 Shadows Demo does nothing

Reported by: bdezonia Owned by: curtis
Priority: minor Milestone: imagej2-b4-plugins
Component: Core Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking: #1011

Description

Running the old Shadows Demo looked like it did nothing. But debug level inspection of logs a while ago showed that the demo was running continuously waiting for ESC to be pressed.

In IJ1 the Shadows Demo continuously munged the pixels and then called updateAndDraw(). In our legacy layer we do no drawing from an updateAndDraw(). We merely record the fact that a change was made. To fix IJ1's Shadows Demo we need to actually draw something in response to an updateAndDraw() call.

Note that if drawing during the run of an IJ1 plugin the munged pixels would be in an ImagePlus and would need to be harmonized back to the appropriate Dataset before display update. Note that this could cause performance problems and might violate some of the legacy layer's assumptions (for instance, maybe it could mess up type tracking?). Further investigation necessary.

Curtis, please review this ticket, we can discuss as appropriate, and the ticket can be assigned as needed.

Change History

comment:1 Changed 8 years ago by curtis

  • Priority changed from major to minor
  • Summary changed from Old Shadows demo did nothing to IJ1 Shadows Demo does nothing
  • Milestone changed from biweekly-2011: Jun-20 to Jul-01 to imagej-2.0-beta2

The current legacy layer design is somewhat limited in the case of Shadows Demo and other interactive plugins. The issue, as Barry says, is that right now updateAndDraw is captured by IJ2 and interpreted to mean that the corresponding ImageJ2 display should be updated when the plugin finishes executing. But in the case of Shadows Demo and potentially other interactive plugins, the execution does not complete until the user presses a key.

Barry and I discussed, and we like the current legacy layer design (flagging updateAndDraw events for later processing) because it is simple and efficient, and is working well for most non-interactive cases. To fix IJ1 Shadows Demo to run as expected in IJ2 would require a substantial reworking of the legacy layer to tie updateAndDraw method calls more directly to IJ2 redraw events. We are already in the middle of a fundamental restructuring (linking IJ1 ImagePlus objects to IJ2 Displays rather than IJ2 Datasets; see ticket #542), would do not want to further alter the nature of the legacy layer until things are working well again.

As such, we will refrain from acting on this ticket until we receive some feedback from the community upon release of the first ImageJ2 beta. If users have many interactive use cases that require a restructuring of the legacy layer, we can do so. But if Shadows Demo is more of an edge case, we can live with the fact that IJ1 Shadows Demo will not run as expected in IJ2. We already have a preliminary IJ2 implementation of Shadows Demo, which should fulfill its main purpose, which is to be invoked interactively from the UI. Conversely, the main purpose of the legacy layer is to enable IJ1 plugins, scripts and macros to continue working particularly in a programmatic context.

comment:2 Changed 7 years ago by curtis

  • Blocking 1011 added

comment:3 Changed 7 years ago by curtis

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

comment:4 Changed 7 years ago by curtis

  • Status changed from new to closed
  • Resolution set to wontfix

Any solution that makes the IJ1 Shadows Demo run as expected would, as suggested above, require a fairly fundamental restructuring of how the legacy layer works. We do not have plans for that currently; rather, we are reimplementing interactive IJ1 plugins. We already have an IJ2 Shadows Demo.

As such, I am closing this ticket with 'wontfix'. If we later decide that some substantial update to the legacy layer is required, it will have a much larger scope than the Shadows Demo anyway, and will be expressed in its own ticket(s) as work progresses.

Note: See TracTickets for help on using tickets.