Menu
▾
▴
gnuplot-beta
|
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 |
|
From: Ethan M. <merritt@u.washington.edu> - 2013-04-06 05:08:16
Attachments:
unzoom_autoscaled_image.patch
|
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 |
|
From: Dima K. <gn...@di...> - 2013-04-08 11:05:07
|
Ethan Merritt <merritt@u.washington.edu> writes: > 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. > > I very much dislike that factor of 1e-3. A better fix would remove it altogether. > How about the attached patch instead. Sounds great. I'm not a fan of that either. >> 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 Looks like you fixed this in the repo. Thanks! dima |
