[JHV 2.1] Problem with zoom scale display in info bar

I had a closer look at this one. From what I can see, the value is only updated, when the renderer has actually new (zoomed) data to display. When zooming out, I first see a "black border" (where the the surrounding data should be display). Only when this "black border" is replaced by the surrounding image data, the zoom value changes.

(This can't be the full story - I just observed some other patterns ...)

However, the component's (ZoomStatusPanel) updateZoomLevel method is called correctly, so the value IS actually refreshed immediately.

The problem seems to be in ZoomController's "getZoom()" method: It only returns the updated (correct) values after "some time".

So to summarize:

Someone with more "renderer knowledge" should have a closer look at ZoomController : getZoom()

Cheers
Malte

So, I had a closer look at this issue.

In my option, the delay has nothing to do with the view chain. The corresponding change event is fired right away. But when the event reaches the GUI-level, it is passed to the class LayersModel, which starts a new thread to pass the event to all GUI-classes. The scheduling of this thread is left to the virtual machine and the operating system. Thus, it is undetermined.

This also explains Malte's observation that the zoom is updated whenever the decoder is ready - When the decoder is not working any more, the CPU is free and thus probability that the update is scheduled is much higher, because no CPU-demanding thread is pending. I am also quite sure that many other effects can be explained by the scheduling. For example, when zooming while playing a move, the update may have to wait several frames or even by pushed over the edge completely, if more and more short-living threads need to be scheduled. We had a similar problem when trying to move all GUI-updates to the AWT event queue, which simply flooded the queue.

@Malte Are these threads necessary? Passing the change event would be quicker and more reliable without using an additional thread...

Okay, this was not threading related at all. Here's my commit message that describes what was going on:

--

After calling JHVJP2View's setRegion() it is in general not guaranteed that
getRegion() will just return the newly set region. Instead, JHVJP2View will
return the last region for which all available data was downloaded. The zoom
scale info bar used this "old" information.

This fix adds a method getNewestRegion to JHVJP2View and makes ZoomController
use this new method.

NOTE: The special behavior of JHVJP2View's getRegion() seems to be needed
for JHV: Directly changing getRegion() to always return the newest region
resulted in very awkward JHV behavior.