Ticket #1566 (assigned defect)

Opened 6 years ago

Last modified 6 years ago

Zoom out is slow

Reported by: bdezonia Owned by: dscho
Priority: major Milestone: imagej2-unscheduled
Component: Core Version:
Severity: serious Keywords:
Cc: Blocked By:
Blocking: #1326

Description

Open embryos and zoom in a handful of steps. Now zoom out repeatedly by pressing minus key. It gets very slow and one does not reach a minimal zoom for a long time (with some zoom steps skipped).

Change History

comment:1 Changed 6 years ago by bdezonia

Happens in beta 5 also. Note that it seems event processing might be tied up (an event storm in place?). A zoom is getting recorded (since steps can get skipped) but not updated on the screen quickly enough.

comment:2 Changed 6 years ago by bdezonia

  • Blocking 1563 added

comment:3 Changed 6 years ago by bdezonia

Note it does not happen with boats. Embryos is big and merged color. Test with different data to narrow. I did. It doesn't happen with clown. It happens some with particles. So its size that is the issue.

Also note that on zoom out threads are getting hatched that are stuck timed waiting. They are named "ImageJ-2578ab1f-Thread-1" etc. Determine if that "ImageJ" prepend refers to IJ1 or IJ12.

We also should consider the possibility that this happens due to a change in IJ1 rather than in IJ2. Run with a different IJ1 version.

Last edited 6 years ago by bdezonia (previous) (diff)

comment:4 Changed 6 years ago by bdezonia

It's IJ2 threads. And it can happen with Boats (just not as easily as embryos). Using print statements I see that zoom ins always quickly pass through the DefaultImageCanvas::setZoom() calls. When repeatedly zooming out the setZoom() has not yet terminated when a new setZoom() call is made.

Note that zoom in should be quick because it requires a scaling of the current image of the canvas. A zoom out may require a new image to be created if the current view is clipped. This would explain why zoom out is slower.

Can inspect commands that are hatched in the "ImageJ..." threads and they are ZoomOut commands. Not sure why the ZoomOut commands are stuck in TIMED_WAITING. No thread wait(0 or sleep() calls have been initiated by IJ2.

comment:5 Changed 6 years ago by bdezonia

Made some changes last week. Now zoom events will be able to be recorded in macros. So now zoom in and zoom out both can show the error. Many threads can get hatched if you press a zooming hotkey repeatedly. Zooms are slow. Threads all seem to be ZoomIn and ZoomOut commands. Can't determine why the threads don't terminate or what they are waiting on. After a long wait they will terminate.

comment:6 Changed 6 years ago by dscho

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

comment:7 Changed 6 years ago by dscho

  • Milestone changed from imagej-2.0.0-beta7 to imagej-2.0.0-beta6

comment:8 Changed 6 years ago by bdezonia

  • Blocking 1574 added; 1563 removed

comment:9 Changed 6 years ago by bdezonia

Some scribblings I had in a notebook before I relinquished this ticket to dcsho:

Threads related to ZoomIn or ZoomOut commands hang around in a TIMED_WAITING state.
Not hanging in syncUI() or syncCanvas(). But note those methods do some event hatching.
Not a reentry prob with sync(). Making it synchronized made no difference.
Removing the accelerators from ZoomIn and ZoomOut no longer fixes any issue.
Is it a weird order of execution in the thread service? investigate.

comment:10 Changed 6 years ago by curtis

  • Blocking 1326 added; 1574 removed
  • Milestone changed from imagej2-b6-legacy-undo to imagej2-b7-ndim-data

comment:11 Changed 6 years ago by bdezonia

  • Milestone changed from imagej2-b7-ndim-data to imageJ-2.0.0-TO-REFILE
Note: See TracTickets for help on using tickets.