Comment 2 for bug 690422

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...