Created attachment 35101 [details]
patch to fix the bug.

The problem was is that as you zoom out the image that was rendered becomes bigger and bigger. Hence once you get to certain size, depending on the system, you are trying to render images that are too big to handle, e.g. 10,000x10,000 pixels.

My system starts to slow down badly at about 10.000 pixels. So I set a harness of 5000 pixels as a limit. Perhaps that should be revised upwards.

Man this is a grave bug. I almost had to restart my computer when trying it
out. Fortunately, with the help of a KPA junior, it should be easily fixed.

The code for zooming is in Viewer::ImageDisplay::zoom(), the algorithms in
there might not be completely trivial, but when you got your head around
it, it should not be that bad. 

Once you've solved this bug, I also suggest you consider if zooming the
other direction should have an upper limit (that is, should it be possible
to show a pixel spread over the whole screen?)

Also, please consider if your fix is needed too in
Viewer::VideoDisplay::zoom methods.

Once you got your head around the zooming code, maybe you could have a look
at bug 166438.

Thanks Alex, the fix has been applied, a few comments FYI.
I changed the test to say:    

if ( ( size.x() * size.y() > 25*1024*1024 ) )
        return;

instead, there are two points to that
1) multiplying the two allows to also avoid the problem, but still be able to zoom well on an odd dimensioned image
2) I prefer early returns instead of nested test in general, so I prefer seeing code like

if (test1)
  return;
if (test2)
  return;

code();

rather than:
if (!test1) {
  if (!test2) {
    code();
  }
}

Thanks for the patch.

My additional hint to the bug was written on Mallorca (without internet), so we crossed each others work here. Maybe you could check if the video part of the suggestion still applies, and produce a patch for that, or alternatively simply close the bug.

Cheers
Jesper.

so this bug can be marked as closed?