Strange behavior when resizing profile plots

[Sethur]

OS: Windows 10 x64 Version:

Description When resizing profile plots on the bottom right corner without previously activating the window, the targeted window size is often not reach during the repainting of the plot. It often happens, that the plot snaps back to its original size, or, when moving back and forth between a larger and a smaller size, snaps back to the larger size.

Here is a GIF showcasing the issue:

Steps for Reproduction

1. Start ImageJ
2. Click on File -> Open Samples -> CT (16-bit DICOM)
3. Select the Line Tool and draw an arbitrary horizonal line somewhere in the image
4. Press Ctrl-K or manually select Analyze -> Plot Profile
5. Without clicking in the title bar of the profile plot window, go to the bottom right corner until the mouse pointer is changed to the diagonal resizing icon. Click and hold the left mouse button.
6. Play around with different window sizes. Depending on the current requested new window size, the repainting of the plot will not match the requested size. Sometimes the plot will jump back to a larger size even though a smaller size was requested, sometimes the opposite occurs.

[Sethur]

@rasband Can you reproduce this? There is a chance that this is JVM dependent, I only tried it with two different Azul builds. Would be nice if this could get fixed...

[rasband]

I am not able to reproduce the problem with repainting the plot not matching the requested size but I do see a lot of flickering on Windows 11 and Azul 1.8.0_345.

[Sethur]

@rasband That is strange, I just did fresh download of the current windows Java bundle of ImageJ v1.54d from imagej.nih.gov, which comes bundled with some (hopefully recommended) JVM 1.8.0_345, and I can easily reproduce the problem.

Drag&drop-resizing any profile plot from the bottom right corner quickly (it seemed like it mostly works if you move the mouse very slowly), i.e. clicking the bottom right corner, holding the left button, and then moving diagonally outwards and back inwards, will often cause repainting glitches, i.e. the window will snap back to some previous size although the mouse pointer is somewhere else (while still holding the button). The glitches happen both when enlarging the current plot or when shrinking it. Releasing the mouse button in a "broken" state (i.e. the window is not at the size that it should be) will then finally produce windows like this (for failed shrinking):

or this (for failed enlarging):

Could this be an OS issue?

[rasband]

What OS are you using? I'm using Windows 11 Home running on a Parallels virtual machine on an M1 (arm64) MacBook Air.

[Sethur]

@rasband I am on Windows 10 Version 10.0.19044.2728 (21H2)

I will try to reproduce this on a different OS.

Time permitting I will also try to have a look into the plot repainting/resizing section of the code, maybe the strong flickering upon resizing can be improved along the line.

[justinjconroy]

I'm on Windows 10 Version 10.0.19045 Build 19045 with latest ImageJ 1.54e46 and seeing the same weird behavior @Sethur had with it snapping back to previous sizes randomly when you resize too fast. After poking around I have figured out a couple things:

• The main thing is the resizeCanvas function of PlotCanvas.java is not thread safe? It appears it gets called multiple times on top of each other before previous instances have finished executing when you do that fast resizing. I thought making it a "synchronized" function would fix it but that didn't seem to help. Instead I ended up adding a simple Boolean check in it to make sure it wasn't already executing and this eliminated it snapping back to previous positions.
• The other thing that I think is wrong in resizeCanvas is the child plot was getting resized before the parent canvas which was introducing some of that extra flickering. Flipping that order of execution helped but still a lot of flickering.

@Sethur If you want to see if this stuff improved the behavior for you also, you can look at my fork here but I don't think I want to do a Pull Request yet until I test it a bit more.

[Sethur]

@justinjconroy Thanks for you efforts, I had wanted to look into this myself but could not find the time until now. I'll definitely test your changes.

[Sethur]

@justinjconroy Did your tests work out?