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 #1180 (closed defect: moved)

Opened 2012-05-15T12:13:16-05:00

Last modified 2013-06-07T16:13:44-05:00

Eliminate redundant update events

Reported by: bdezonia Owned by: curtis
Priority: major Milestone: imagej2-b8-analysis
Component: Display API Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking: #1358

Description

Many plugins take a display as a parameter but munge it's associated Dataset generating Dataset::update() events. Calling Dataset::update() will set off a chain of events that will eventually call Display::update() on all Displays containing that Dataset.

Currently, declaring a Dataset @Parameter as ItemIO.BOTH will cause DisplayPostprocessor to generate a second Display::update() for all Displays containing that Dataset, which is redundant and potentially wasteful.

However, it is vital that the Dataset be labeled as ItemIO.BOTH because it *is* also an output of the plugin, and downstream code needs to know that.

This ticket came from ticket #1020

I can think of a couple different solutions, but none of them seems obviously and unequivocally best to me:

  • All concrete implementations of Display become smart enough that calling update() twice in a row does nothing on the second call, because there is nothing left to do. This would entail more careful tracking of what has changed. It also makes doing a "forced refresh" of the display potentially less intuitive, as we would then need a separate method or toggle for doing that.
  • The DisplayPostprocessor somehow becomes smart enough to avoid calling Display::update() on Displays that were already updated during plugin execution, either directly or as part of an event chain, such as when calling Dataset::update(). I am not entirely sure how we would track that though.

Change History

comment:1 Changed 2012-07-13T22:10:48-05:00 by curtis

  • Blocking 1052 added

comment:2 Changed 2012-07-13T22:11:11-05:00 by curtis

  • Blocking 1325 added

comment:3 Changed 2012-08-03T10:40:09-05:00 by curtis

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

comment:4 Changed 2012-08-03T10:40:27-05:00 by curtis

  • Blocking 1357 added

comment:5 Changed 2012-08-03T10:41:04-05:00 by curtis

  • Blocking 1052 removed

comment:6 Changed 2012-08-03T10:45:12-05:00 by curtis

  • Blocking 1358 added

comment:7 Changed 2012-08-03T10:45:33-05:00 by curtis

  • Blocking 1325 removed

(In #1325) Pushing some tickets to beta5; see #1358.

comment:8 Changed 2013-03-19T10:52:59-05:00 by curtis

  • Status changed from new to accepted
  • Milestone changed from imagej2-b7-ndim-data to imagej2-b10-compatibility

comment:9 Changed 2013-03-19T10:53:49-05:00 by curtis

  • Blocking 1357 removed
  • Milestone changed from imagej2-b10-compatibility to imagej2-b7-ndim-data

Not sure why this was blocking #1357... it is a display architecture issue.

comment:10 Changed 2013-06-07T16:13:44-05:00 by curtis

  • Milestone changed from imagej2-b7-ndim-data to imagej2-b8-analysis

comment:10 Changed 2014-07-12T22:26:13-05:00 by curtis

  • Status changed from accepted to closed
  • Resolution set to moved