Ticket #1566 (assigned defect)
Opened 2012-11-07T15:24:28-06:00
Last modified 2013-01-22T12:45:23-06:00
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 2012-11-07T15:27:16-06:00 by bdezonia
comment:3 Changed 2012-11-07T15:59:59-06:00 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.
comment:4 Changed 2012-11-21T13:28:07-06:00 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 2012-11-27T12:53:04-06:00 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 2012-11-27T13:09:22-06:00 by dscho
- Owner changed from bdezonia to dscho
- Status changed from new to assigned
comment:7 Changed 2012-11-27T13:09:30-06:00 by dscho
- Milestone changed from imagej-2.0.0-beta7 to imagej-2.0.0-beta6
comment:9 Changed 2012-11-29T14:53:58-06:00 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 2012-12-27T11:00:14-06:00 by curtis
- Blocking 1326 added; 1574 removed
- Milestone changed from imagej2-b6-legacy-undo to imagej2-b7-ndim-data
comment:11 Changed 2013-01-22T12:45:23-06:00 by bdezonia
- Milestone changed from imagej2-b7-ndim-data to imageJ-2.0.0-TO-REFILE
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.