|
From: Dima K. <gn...@di...> - 2013-04-05 09:08:33
|
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 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. dima |