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

Opened 2012-05-18T15:05:09-05:00

Last modified 2013-06-13T09:50:46-05:00

Adding an overlay resets image zoom

Reported by: curtis Owned by: curtis
Priority: critical Milestone: imagej2-b8-analysis
Component: Display API Version:
Severity: serious Keywords:
Cc: mohammedtleis@…, rob.vanthof@… Blocked By:
Blocking: #1358

Description (last modified by curtis)

Adding or removing an overlay causes a display rebuild operation, which currently always resets pan and zoom, and repacks the display.

Change History

comment:1 Changed 2012-05-18T15:06:40-05:00 by curtis

To reproduce: Open Blobs, zoom in a couple of times, then add a point ROI. The window will reset to 100% zoom.

comment:2 Changed 2012-05-18T15:07:03-05:00 by curtis

  • Blocking 1143 added

comment:3 Changed 2012-05-18T16:39:00-05:00 by curtis

See also #933.

comment:4 Changed 2012-05-22T13:37:44-05:00 by bdezonia

With commit 10033c5e0cc75cd40f5ebd83c0a7400b12f28966 rebuilds are called more consistently. There was a bug that was keeping overlay deletion from triggering rebuilds. The commit bugfix has actually made things worse in turns of zoom resets. We need to redo how a display (or specifically AbstractDisplay) decides if it needs an update or a rebuild.

comment:5 Changed 2012-05-30T11:11:41-05:00 by bdezonia

  • Owner changed from bdezonia to curtis
  • Status changed from new to assigned

Curtis, I think this will require a display refactoring of some kind. I'd like to pass this to you. If not then assign back to me with comments.

comment:6 Changed 2012-06-08T12:54:57-05:00 by curtis

  • Component changed from other to ij-display

comment:7 Changed 2012-07-03T13:26:11-05:00 by bdezonia

  • Blocking 285 added

comment:8 Changed 2012-07-03T13:28:24-05:00 by bdezonia

  • Blocking 1143 removed

comment:9 Changed 2012-07-12T10:55:50-05:00 by curtis

  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4
  • Blocking 1326 added; 1185 removed
  • Version 2.0.0-beta2 deleted
  • Description modified

comment:10 Changed 2012-07-12T10:57:27-05:00 by curtis

  • Description modified

Very unfortunately, this behavior still exists. It should not be too bad to resolve with some improvements to the display update mechanism, but we have not yet had time to do so.

comment:11 Changed 2012-07-12T10:57:53-05:00 by curtis

  • Priority changed from major to critical

comment:12 Changed 2012-07-17T11:50:14-05:00 by bdezonia

  • Cc rob.vanthof@… added

comment:13 Changed 2012-09-06T14:12:17-05:00 by curtis

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

comment:14 Changed 2013-01-22T12:44:39-06:00 by bdezonia

  • Milestone changed from imagej2-b7-ndim-data to imageJ-2.0.0-TO-REFILE

comment:15 Changed 2013-01-23T09:07:52-06:00 by bdezonia

  • Blocking 285 removed

comment:16 Changed 2013-04-15T11:07:22-05:00 by curtis

  • Status changed from assigned to accepted
  • Blocking 1358 added; 1326 removed
  • Milestone changed from imagej2-unscheduled to imagej2-b7-ndim-data

comment:17 Changed 2013-06-07T16:01:12-05:00 by curtis

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

I am so disappointed that I still haven't fixed this bug. It is incredibly irritating. But it will go hand in hand with the display refactoring on the display-refactor branch. But there are too many other priorities before that branch can be completed, so will not make it into beta7.

comment:18 Changed 2013-06-13T09:50:46-05:00 by bdezonia

  • Cc mohammedtleis@… added

comment:10 Changed 2014-12-18T12:36:28-06:00 by curtis

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