#336 Refresh plot or zoom without re-reading data
This patch adds a new command 'refresh' that acts similarly to 'replot' except that it does not re-read or recalculate the input data. This allows you to zoom, add labels, or otherwise modify the current plot even if the input data is transient. In particular it allows you to zoom or otherwise modify a plot whose data came from stdin, e.g. plot '-'.
Data processing is modified in these ways:
1) Plot data is not discarded immediately after a successful plot command. Instead it is kept around until it is replaced by a subsequent plot or replot command. This is a change for 2D plots. 3D plots already worked this way.
2) The new command 'refresh' is implicitly used by mouse zooming operations. Because the axis ranges may have changed since the data was read in, we must walk through the data and re-evaluate the INBOUNDS/OUTBOUNDS flag for each point before regenerating the plot.
3) I had to re-work the way zoom operations are saved/restored. It is actually a simplification of the existing code, but the behaviour of "unzoom" is now subtly changed if it is triggered from a different plot than the original zoom operation. The old behaviour was undocumented, so I am not too worried about this at the moment.
Known issues in the first version (22 May 2007):
- Quick refresh is not yet implemented for 3D plots (splot + set view map).
- Only the primary x and y coordinates of each point are rechecked against the current axis limits. Possibly this is not sufficient for some plot styles (errorbars? candlestick?) Easy to fix if needed.
- There should be some way to turn off the quick refresh if you really do want to re-read the data during a zoom operation. Maybe a new command
set zoom {replot|refresh}
or
set mouse zoom {replot|refresh}
Logged In: YES
user_id=235620
Originator: YES
Petr said:
<<
(*) There is a strange thing/bug:
unset grid
plot ... volatile
Now zoom several times, hit "g" for grid on, then hit "u" for unzoom => grid is lost. This does not happen with "u" in the other usage of the plot command.
>>
Yes. This is because the grid settings are stored as part of the individual axis structures. When you "unzoom", the original axis settings are restored, which includes the old grid settings. When you do a full "replot" command, the axis structures are filled in all over again rather than being re-used.
If this is a problem, I suggest that the proper answer is to move the grid settings out of (struct axis) into a new self-contained structure. I may be overlooking something, but I don't see why the grid needs to be a property of the axis at all. It should be sufficient to define two bitfields for toggling axis tics on/off. For example:
extern int grid_majortics, grid_minortics;
/* Set major but not minor tics for the y2 axis */
grid_majortics &= 1 << SECOND_Y_AXIS;
grid_minortics |= ~(1 << SECOND_Y_AXIS);
"refresh" and zoom without re-reading data Ver3
Logged In: YES
user_id=235620
Originator: YES
Version 3
- Autoscale works
- Reversed axes work (but see note below)
- 'l' and 'L' hotkeys trapped before execution if volatile data present
Note: 4.0, 4.2, and current CVS all seem to have a bug in the 'u' hotkey processing that results in losing the previous state of axis reversal. This patch triggers the bug under different conditions than the earlier versions. To be investigated and fixed separately.
File Added: persistent_plot_data_28jun2007.patch
Logged In: YES
user_id=235620
Originator: YES
Version 4
This one is for real. Please give it a workout.
- Autoscale works
- Reversed axes work
- set view map; splot .... works
- debugging options removed or silenced
Known issues:
- plot; zoom; toggle grid; unzoom; returns to original grid setting
- contour lines are not clipped properly to the edge of the graph
File Added: persistent_plot_data_29jun2007.patch
"refresh" and zoom without re-reading data Ver4
Logged In: YES
user_id=31505
Originator: NO
Great work!
I tried the patch from within gnuplot and via octave. It works fine.
When you are committing the patch, I propose to commit it to both 4.3 and 4.2.
Ver5 - will commit to CVS unless there are screams
Logged In: YES
user_id=235620
Originator: YES
I've committed some pieces to CVS already as preliminary cleanup. Version 5 (30 June) patch contains the core changes implementing "refresh", which I will commit in the next few days unless someone turns up problems. There will be another round of minor cleanup afterward.
Known problems:
- You can break zoom/unzoom of parametric plots with volatile data
if you try hard enough.
To be decided:
- Which axis properties (e.g. whether to draw grid lines) should
be saved and restored across zoom operations
- Do we want another hot-key that does a forced replot?
(I.e. reread volatile input data)
- At what point does the "unzoom" option expire?
File Added: persistent_plot_data_30jun2007.patch
Logged In: YES
user_id=704782
Originator: NO
A long time ago I had proposed a method for zooming in X11 that doesn't re-read data, in fact didn't even use the gnuplot core. It simply magnified the image. Hans argued that that wasn't acceptable because there should be new tic marks and higher resolution for the functions, if I recall correctly. With that in mind, this approach also has the loss of resolution. Since the function data is not resampled, only the range is changed with the data left as is, something like
gnuplot> plot '-' with points, sin(x) with points
input data ('e' ends) > -10 0.8
input data ('e' ends) > -5 0.4
input data ('e' ends) > 0 0.1
input data ('e' ends) > 5 -0.6
input data ('e' ends) > 10 0
input data ('e' ends) > end
when zoomed using the mouse shows that the function sin(x) is losing resolution when I think the accepted behavior of current CVS is to not lose resolution.
One can illustrate this problem in other ways. Try
reset
plot sin(x/3) with lines
set xrange [-20:20]
refresh
replot
Notice how the sample range for the function portion of the plot remains from [-10:10] while the display range is [-20:20] in the case of "refresh". That does not match the behavior of the accepted convention for the "replot" case.
This approach seems too far from the desired behavior with no easy fixes if it were put in CVS.
Patchset as commited to CVS 31 Aug 2007
Logged In: YES
user_id=235620
Originator: YES
Because the current Octave requires some way to zoom or replot volatile data, I am moving this patchset into CVS. I acknowledge that it is not a perfect solution, but we need something in place for Octave users even if we replace it with a better solution later on.
To facilitate later replacement, if necessary, I have set off the code pieces with #ifdef VOLATILE_REFRESH and placed this under the control of a new configuration option --enable-volatile-data
File Added: persistent_plot_data_31aug2007.patch
Logged In: YES
user_id=31505
Originator: NO
Gnuplot compiled from cvs; now zooming works fine with Octave 2.9.x, thanks.
Logged In: YES
user_id=31505
Originator: NO
I think this functionality is already in cvs, isn't it?
It seems that only either of these
set zoom {replot|refresh}
set mouse zoom {replot|refresh}
commands were not implemented, and the default is "refresh". It seems enough, because for "replot", you can hit "e".
Is this functionality in gnuplot now? As of which version? Is there a request filed to track this feature that I can follow?
It doesn't work for me in version 4.2.3. That is, loading test.gnu (below) is not zoomable, and separating the data into its own file is zoomable.
test.gnu:
plot '-'
1 1
2 2
e
A test:
$ which gnuplot
/opt/gnuplot-4.2.3/src/gnuplot
$ gnuplot
G N U P L O T
Version 4.2 patchlevel 3
last modified Mar 2008
System: Linux 2.6.18-6-686
...
Terminal type set to 'x11'
gnuplot> load "test.gnu"
I found something.
See [ 1783514 ] Allow mouse zoom with stdin data.
It claims it is fixed in the mainline of 4.3 in 2007. IMHO, that feature request shouldn't be closed, as the current released version over a year later is 4.2.4.
New features go into the development version, which is currently 4.3.
If the addition is minor, and the patchset applies cleanly to the older source as well, then it may be back-ported to the next incremental version of the current release.
This particular patchset was fairly major restructuring of the data input process, and it is not likely that it will be back-ported to version 4.2
This patchset has been closed because it is suspected to be obsolete. Possible reasons include
(1) the patch no longer applies against current cvs
(2) strong resistance was expressed during discussion
(3) an equivalent capability has been added since the patch was submitted
(4) we no longer remember or don't understand what the patch was intended to fix
If this is your patchset and you think that it is still relevant, please re-submit a revised version against the current CVS source.