return correct sized tuples of all 0s not None if image plot resized too small

[aaronayres35]

fixes #528 (I think)

With the change made in this PR I no longer see the crash described here: #528 (comment)

This PR simply updates _calc_zoom_coords to return what it claims to return:

Returns
-------
    index_bounds : 4-tuple
        The column and row indices (col_min, col_max, row_min, row_max) of
        the sub-image to be extracted and drawn into `screen_rect`.
    screen_rect : 4-tuple
        (x, y, width, height) rectangle describing the pixels bounds where
        the image will be rendered in the plot.

In this particular case if we have zoomed in so far that the image has either length or width 0, the the screen rect showing it is effectively non-existent, and there is no data to show in it.
Technically ((0, 0, 0, 0), (0, 0, 0, 0)) isn't really the exactly correct thing to return here (instead you could think that screen_rect should be a 0x0 rectangle at the point where the image should be on screen, not at x=0, y=0). However, there is actually nothing to draw so it effectively doesn't matter.

The only place this method is called is by _compute_cached_image. If _compute_cached_image gets ((0, 0, 0, 0), (0, 0, 0, 0)) everything works out as expected as we end up with data=data[0:0, 0:0] making data.shape = (0, 0, 3) and a screen_rect that is 0x0.

Note: now when I slowly shrink the window once I hit the critical point rather than the example crashing, I see:

/Users/aayres/Desktop/chaco/chaco/axis.py:613: RuntimeWarning: invalid value encountered in true_divide
  self._axis_pixel_vector = self._axis_vector/sqrt(dot(self._axis_vector,self._axis_vector))

This is not new from the changes in this PR (was masked by the crash previously), but occurs because we end up with an _axis_vector of (0, 0) when we shrink that far

[rahulporuri]

I tested this locally by checking the example https://github.com/enthought/chaco/blob/174342ff70f78941f011656cc994a9c28463c547/examples/demo/image_plot_origin_and_orientation.py - and that example doesn't crash on this branch - whereas the example crashes on the main branch.

But, I don't like the fact that I can squeeze the window horizontally and vertically into an absurd state. But, an working application in an absurd state is better than a crashed application i guess?

[rahulporuri]

This is not new from the changes in this PR (was masked by the crash previously), but occurs because we end up with an _axis_vector of (0, 0) when we shrink that far

I'm not sure why an _axis_vector would raise that runtime warning. Did you mean _axis_pixel_vector? It'd be useful to investigate what is actually causing that runtime warning - and maybe open an issue for it.

[rahulporuri]

Code changes LGTM. It'd be awesome if you could put together a regression test for this change, that would be awesome.

Let's wait for the devs who reported the issue to also get back to us.

[rahulporuri]

@jvkersch any chance you can take a few minutes to look at this PR and the issue #528 ?

[sallenEnth]

@aaronayres35 @rahulporuri I tested and I don't see the bug anymore. Thank you for the fix.

[aaronayres35]

this test is a little ugly namely from the 101 magic number. I was unsure how to better write this test.

Without the fix this test fails, with it it passes.

[aaronayres35]

It'd be awesome if you could put together a regression test for this change, that would be awesome.

I've attempted to write a regression test like how we discussed. It seems to do the trick although it is a little ugly. I added a comment to hopefully clear up the nature of the test / the magic number

[rahulporuri]

Still LGTM