#677 Fixed many small mouse-triggered-zoom bugs

[dima]

Before this patch

• zoom-around-mouse (ctrl-wheel) did not work with volatile data

• horizontal zoom (shift-ctrl-wheel) was not mouse-centered

• the bounds of inactive axes (those with VERYLARGE bounds) were being changed
  when zooming. Now the bounds stay at +-VERYLARGE regardless of zooming

The causes of these issues (fixed in this patch) were improper handling of the
log axes, not paying attention to the order of bounds (in case an axis was
reversed), etc

[Ethan Merritt]

Oops.
Insufficient testing.

I am reverting this patch because it breaks normal zooming.
For example:
gnuplot> plot 'silver.dat'
zoom central region with mouse
plot is now zoomed, but the x axis range is reverse.
Sometimes (but it seems not always) the y axis range is reversed also.

Given that the patch does multiple things, could you please break it up into pieces that can be tested and applied individually?

thanks,

Ethan

[dima]

Hi Ethan.

I'm happy to break up the patch, but I'd like to observe the issue you're describing first. I am having trouble reproducing it. Can you post exact xrange/yrange values that are problematic?

[Ethan Merritt]

I don't think it matters what the ranges are. One thing that does matter is the order in which you select a zoom box. That is, click+drag from upper right to lower left gets you a different plot than click+drag over the same range from lower left to upper right.

[dima]

Hmmm. I tried all 4 directions with both x11 and qt terminals and two different builds of gnuplot (one being the latest CVS copy with the patch re-applied). It always looks fine here. I'm on amd64 Debian. You're sure the failure you're seeing is related to this patch?

[Ethan Merritt]

I bisected it to that change/date. But upon closer inspection I see that there was a 2-day window in which the definition of sgn(x) was dubious. My bisection was not fine enough to catch that interaction.

Date       mouse.c  status
---------------------------
28-Apr      1.160   good
28-Apr noon 1.161    bad
29-Apr      1.162    bad
                        <- stdfn.h definition of sgn(x)
01-May      1.162   good

That doesn't explain why I was still getting bad builds from yesterday's cvs. Perhaps it means my copy stdfn.h was not getting updated because it had been locally modified.

Sorry for the noise - I'll sort it out.