[Domterm-discuss] DomTerm question/suggestion

[Per Bothner]

A quick preliminary reply for now - I will be traveling and otherwise
busy today.

On 11/9/20 10:57 AM, Ethan Merritt wrote:

> 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.

After I did the gnuplot support, I added a feature to replace in-place
an existing image.  It is used for the Python support:

http://domterm.org/Python-tips.html

The escape code used is described here:
http://domterm.org/Wire-byte-protocol.html
Search for "721" or "Replace previously-inserted HTML".

Also check the tools/python sub-directory of the DomTermn source tree
for how the Python support works.

> 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.

That seems to be the documented effect: "Delete all lines in the buffer ... except the current line."

> 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.

Would the 721 escape code mentioned above work?  Probably worth an effort.
Are you comfortable working on the gnuplot C code?  If not, I can try.

Another idea: SVG has a mechanism for animation.   If gnuplot can
make use of these, we could add escape sequences that modify
SCG properties such that animation happens.  I don't know much about this.

> 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.

Well, DomTerm does implement the standard xterm mouse-reporting mechanism.
It only reports the mouse position in terms of rows and columns.
(An image is treated as a single large character in an extra-tall line.)

> 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.

This is mouse-reporting protocol(s) implemented by xterm (and DomTerm):
https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h2-Mouse-Tracking

I suspect that isn't enough.  Do enough of these other terminal
that report mouse position at the pixel level use an escape sequence
protocol, or does gnuplot make directly calls to access the mouse?
The former should be easy enough (easier if there is documented prior
art); the latter would be a problem.  (We want this to
work over an ssh connection, for example.)

-- 
	--Per Bothner
per at bothner.com   http://per.bothner.com/