#677 Fixed many small mouse-triggered-zoom bugs

Version 5

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

1 Attachments


  • Ethan Merritt

    Ethan Merritt - 2014-04-27
    • status: open --> closed-accepted
  • Ethan Merritt

    Ethan Merritt - 2014-05-08

    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?


  • Ethan Merritt

    Ethan Merritt - 2014-05-08
    • status: closed-accepted --> open
  • dima

    dima - 2014-05-08

    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

    Ethan Merritt - 2014-05-08

    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

    dima - 2014-05-08

    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

    Ethan Merritt - 2014-05-09

    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.

    Last edit: Ethan Merritt 2014-05-09
  • Ethan Merritt

    Ethan Merritt - 2014-05-14
    • status: open --> closed-accepted

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks