Re: [PATCH] The autoscaling of images during volatile data refresh works again

[Ethan M. <merritt@u.washington.edu>]

On Friday, 05 April 2013, Dima Kogan wrote:
> I'm attaching a patch that fixes another set of issues with refreshing
> volatile data: autoscaling of images. To observe the issue being fixed,
> start up gnuplot and issue
> 
>  load "volatile_image_refresh.gp"
> 
> where the given file is the attached test case. This is the blutux.rgb
> demo image, but stored inline, rather than as a separate file. The load
> will succeed. If you then refresh the plot with 'e', the axis ranges
> will get confused.
> 
> The attached patch fixes this issue, which is actually a regression from
> an earlier bug fix. The earlier bug fix reduced the range of the data
> that gnuplot can use by 1e6 for the volatile-refresh case. This was
> confusing things, so the attached patch makes this range adjustment for
> /all/ data. If we can figure out exactly what this original range
> reduction was fixing, maybe a better solution can be found. Comment from
> the patch and the code:
> 
>  This was a regression, caused by an unrelated bug fix that modified the meaning
>  of VERYLARGE in some cases. Relevant comment:
> 
>  An earlier bug fix introduced this factor in some narrow circumstances
>  (AXIS_INIT2D_REFRESH macro) to get around some overflow issues. However, this
>  broke some autoscaling functionality (specifically 2d image autoscaling when
>  refreshing volatile data) because the STORE_WITH_LOG_AND_UPDATE_RANGE() macro
>  has == comparisons with VERYLARGE. Here, I apply the factor to VERYLARGE always.
>  The bug fix in question is in the commit titled
> 
>   Date: Sun Mar 23 21:39:26 2008 +0000
>   Fix macros AXIS_INIT2D_REFRESH and AXIS_UPDATE2D_REFRESH so that the refresh
>   command for volatile data works correctly for log axes (SF 1916494).
> 
>  The bug it refers to is http://sourceforge.net/p/gnuplot/bugs/636/
> 
>  The comment in that commit was
> 
>  if an already VERYLARGE x2 and y2 ranges are
>  calculated after zoom-out by mouse, then they would become even larger

I very much dislike that factor of 1e-3.  A better fix would remove it altogether.
How about the attached patch instead.

> Re-enabling the first two commented-out lines in the test case reveals
> yet another set of issues. I'll look at those in a bit.

The remaining problem I see is shown by adding to your test script
set x2tics
set y2tics

Since there is no x2 or y2 data the autoscaling on those axes
never happens, leading to an error equivalent to the one you
found.  Possible fixes:

If the axis min/max is still set to the initial autoscaling magic
constants +/-VERYLARGE either
  1) don't try to draw tick marks or
  2) clone primary axis limits into secondary axis

	Ethan