Ticket #1060 (closed defect: fixed)

Opened 7 years ago

Last modified 4 years ago

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 7 years ago by bdezonia

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.

comment:2 Changed 7 years ago 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().

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

comment:3 Changed 7 years ago 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 7 years ago 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 7 years ago 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.

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

comment:6 Changed 7 years ago 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 7 years ago 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.
  • 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.
Version 1, edited 7 years ago by bdezonia (previous) (next) (diff)

comment:8 Changed 7 years ago 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 7 years ago 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 7 years ago by bdezonia

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

comment:11 Changed 7 years ago by curtis

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

comment:12 Changed 7 years ago by curtis

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

comment:13 Changed 7 years ago 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 7 years ago 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 7 years ago 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:16 Changed 7 years ago by curtis

  • Blocking 1185 added

comment:17 Changed 7 years ago 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 7 years ago by curtis

  • Blocking 1326 added; 1185 removed
  • Milestone changed from imagej-2.0.0-beta3 to imagej-2.0.0-beta4

comment:19 Changed 7 years ago by curtis

  • Blocking 1439 added

comment:20 Changed 7 years ago by curtis

  • Blocking 1326 removed

comment:21 Changed 7 years ago by curtis

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

comment:22 Changed 4 years ago 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...

Note: See TracTickets for help on using tickets.