[Domterm-discuss] DomTerm question/suggestion
Ethan Merritt
eamerritt at gmail.com
Mon Nov 9 10:57:19 PST 2020
I have been revisiting the gnuplot + domterm combination for the first
time in a couple of years. Both have seen significant additions since
I last looked. I am now able to build and use the qtdomterm variant
(configure --with-qtwebengine), which works nicely with gnuplot output
embedded.
There is one area where I hope there is room for improvement -
animation/dynamic rotation of 3D plots.
As it stands, each gnuplot 'plot' or 'splot' command creates a
new output image, i.e. one frame of an animation or one incremental
change in the view angle of a 3D rotation. This image is added to
the display buffer and the terminal view is scrolled to show it
at the top of the window. As the buffer gets larger and larger
the process slows down approximately linearly. If I set a rotation
loop going to view a surface from all sides, I see approx 5 frames
per second for the first 50 frames, 3 fps for the next 50 frames,
1 fps for the third 50 frames, etc. It is soon annoyingly slow.
This is benchmarked by repeatedly running a 50-frame loop in a
gnuplot session using "set term domterm" in an instance of qtdomterm.
Contrast this with running the same animation loop after resetting
the buffer and switching to "set term sixel animate" in the same gnuplot
session. The "animate" keyword to gnuplot tells it to reset each
output image to overwrite the same area in the display buffer
(sixel command sequence "\033[H"). Without this keyword the sixel
output suffers the same linear decay in display speed as the svg output.
I tried adding a "clear-buffer" command sequence "\033[7J" to the loop
used in the svg case but this does not work as desired.
The timing does become approximately constant, but rather slow.
Furthermore it has the unexpected effect of making all output before
the final frame invisible. I don't understand why, but this makes
the attempted fix useless.
AIUI, domterm writes a new html/javascript element for each gnuplot
output frame. These pile up in the buffer even though only the
most recent one is visible without manual scrolling. The ever-inceasing
buffer size makes successive display updates gradually slower.
My understanding of how domterm works runs low at this point so I
am not sure exactly what might be possible to improve things.
Would it be possible to change this so that instead of adding a
new element for each new frame, successive frames overwrite or
replace the element being displayed? The total buffer size would
remain approximately constant and I would expect the display rate
to remain independent of the number of frames previously displayed.
I.e. behavior would be analogous to that of gnuplot's"sixel animate"
output.
Separate from this, I wonder if a mechanism already exists or
could be added to feed back mouse coordinates from the qtdomterm
window to an embedded gnuplot session. Gnuplot provides example
javascript routines to handle minimal mousing in svg output
displayed directly (not through domterm), but this capability is
minimal compared to what the core gnuplot code could do if it saw
the mouse coordinates as it does in interactive terminals (qt wxt x11).
The DomTerm documentation indicates that it does track mouse
locations, but I have not found any hint as to how gnuplot might
be able to access that.
best regards
Ethan
More information about the Domterm-discuss
mailing list