Ticket #1060 (closed defect: fixed)
Opened 2012-03-07T14:24:55-06:00
Last modified 2014-12-18T12:38:49-06:00
Zoom out does not pack() correctly
| Reported by: | bdezonia | Owned by: | curtis |
|---|---|---|---|
| Priority: | major | Milestone: | imagej-2.0.0 |
| Component: | Display API | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1439 |
Description
When you zoom out the window does not pack entirely. Sometimes its because the window title is too wide but usually that is not the case. Figure out why its not packing completely and address.
Note that if you repeatedly alternate between zoom in and zoom out the zoom out's accuracy bounces between two states.
Change History
comment:1 Changed 2012-03-12T13:42:47-05:00 by bdezonia
comment:2 Changed 2012-03-12T14:00:12-05:00 by bdezonia
Note that zooming in now sometimes draws what look like unnecessary scrollbars. And if you zoom out on tree rings you'll see sometimes it leaves scrollbar room unnecessarily and sometimes not. You can repeatedly zoom out and the scroll bar space will come and go. Weird.
Note for context that the previous code fixes were tied to getPreferredSize() and maybeResizeWindow(). The scrollbar space should only affect getPreferredSize().
comment:3 Changed 2012-03-12T14:24:58-05:00 by bdezonia
Zooming out behaves better with cdba4f55a2d9780b481ba122556a9f0f9112470b. Trees no longer leaves too much space for nonexistent scroll bars.
There is still the issue that zooming in will say scroll bars are not needed and yet they somehow are generated unnecessarily.
comment:4 Changed 2012-03-12T16:22:09-05:00 by bdezonia
With 5e36dc34d71dae6600a37ab298bf145bb6230256 zoom behavior of scrollbars appears to be much better.
There is still an issue where if you zoom way out the scrollbar space appears unnecessarily and does not go away for a couple zoom ins.
comment:5 Changed 2012-03-13T09:23:33-05:00 by bdezonia
CURRENT STATUS
Occasional zoom hiccups:
- if the first zoom you do is a zoom out space is left for scrollbars. The size of the existing scrollbars are 0 and thus subtraction has no effect.
- if you zoom way way out eventually scrollbar space reappears. at those levels zooming is truncated since going too small and thus scale does not change. thus by definition we are not zooming out and scrollbar sizes are not deleted. We need some other mechanism in getPreferredSize() then.
- if you zoom in on boats = 300% and then zoom out the window does not resize correctly and a lot of whitespace is left around. This might be a different bug.
Must test situation where image comes in at something > 1x due to image size. How well do the scaling rules work there? Right now I cannot do so since not enough memory available in IJ2 to load such images.
comment:6 Changed 2012-03-14T13:32:47-05:00 by bdezonia
Note: JHotDrawImageCanvas::getPreferredSize() needs to be smarter. If you take a new 256 x 256 image and add an axis the view is zoomed such that the blank scrollbar space is present.
comment:7 Changed 2012-03-22T14:38:11-05:00 by bdezonia
- Milestone changed from imagej-2.0-beta1 to imagej-2.0-beta2
With 3e9f2f80fb1f6c053b1adaa7473d56b195734a63 zoom packing greatly improved. I will push the rest of this ticket to a later release.
TODO
- the fix in JHotDrawImageCanvas::getPreferredSize() is somewhat hacky. Need to determine what off by 1/4/5 error is hiding. (Note that #626 historically had something to do with 1/4/5 sizing tweaks)
- if you zoom in on boats = 300% and then zoom out the window does not resize correctly and a lot of whitespace is left around. This might be a different bug.
- on Linux if you zoom out on boats a lot and then start zooming in again sometimes extra whitespace is reserved for nonexistent scrollbars.
comment:8 Changed 2012-05-04T14:41:33-05:00 by bdezonia
Recently someone chnaged JHotDrawImageCanvas::getPrerredSize(). It no longer has the same kind of fudge factors. On Linux there are no longer any zoom in/out whitespace issues.
The 300% comment applied to Barry's work desktop Mac and will be tested again soon.
comment:9 Changed 2012-05-07T15:31:06-05:00 by bdezonia
On my desktop mac the 300% issue still exists. Using hotkeys (+ and -) bounce between 200% and 300% repeatedly. Windows resize in three different ways, cycling between them.
comment:10 Changed 2012-05-14T11:10:14-05:00 by bdezonia
- Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4
comment:11 Changed 2012-05-16T16:10:32-05:00 by curtis
- Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0-beta2
comment:12 Changed 2012-05-16T16:10:42-05:00 by curtis
- Owner changed from bdezonia to curtis
- Status changed from new to accepted
comment:13 Changed 2012-05-17T13:33:29-05:00 by curtis
- Status changed from accepted to closed
- Resolution set to fixed
I believe this is fixed with the recent display fixes, culminating in ce62a731252096c796d25eac4c168a1e566305af.
comment:14 Changed 2012-05-17T13:47:40-05:00 by bdezonia
- Status changed from closed to reopened
- Resolution fixed deleted
Unfortunately I can reproduce the bouncing between scale problem on my laptop on Linux with m51 galaxy between 150% and 100%.
comment:15 Changed 2012-05-17T13:48:48-05:00 by curtis
- Milestone changed from imagej-2.0.0-beta2 to imagej-2.0.0-beta3
Thanks Barry. I am pushing to beta3, so we can get the beta2 release out today, since this problem is annoying but minor.
comment:17 Changed 2012-07-05T16:04:22-05:00 by curtis
As of 1bb013f3, zooming out still does not pack completely. However, the behavior is much more consistent. Zooming in always packs correctly, and zooming out always leaves some space on the bottom and right edges. And the 200%/300% Boats zoom behavior seems to be resolved.
comment:18 Changed 2012-07-12T10:53:22-05:00 by curtis
- Blocking 1326 added; 1185 removed
- Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4
comment:21 Changed 2012-08-27T14:45:10-05:00 by curtis
- Milestone changed from imagej-2.0.0-beta4 to imagej-2.0.0
comment:22 Changed 2014-12-18T12:38:49-06:00 by curtis
- Status changed from reopened to closed
- Resolution set to fixed
Closing as "good enough for now"—especially since the Swing UI is not the default right now anyway. This issue will probably rise again someday, after the Swing UI is in more use. But that UI may undergo substantial changes before that happens...
Improvements in place with 940e9d1f454c49f9097bf22bc29d2582e5f9a9d2 and c79455853eb79b001001a47ad25ac10d351594e7. These are not final fixes but improve behavior for beta 1. Further work required to always correctly add/remove scrollbar sizes based upon window scale.