[Domterm-discuss] DomTerm question/suggestion

[Ethan Merritt]

On Monday, 9 November 2020 12:29:17 PST Per Bothner wrote:
> 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

D'oh!  That you for that pointer.
For some reason I did not find that protocol description page.
I found the "\033[7J" sequence by grepping the DomTerm source
for reset-buffer.  Now I see that "\033[3J" is the sequence I wanted.
With that change I can get domterm animation working like
sixel animation.  Great! 

> Search for "721" or "Replace previously-inserted HTML".

That might be even better, but I'll have to modify the gnuplot
source code to try it.  That can be a project for next week.
I'll get back to you if I have further questions.

> [snip]

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

That would suffer from the original problem, I think.
SVG animation switches amongst previously loaded frames.
But I wanted to avoid having all the frames present at one time
because it makes the rendering too slow.

Now a new thought strikes me, however.
Is it slow merely because the buffer is large, or is it slow
because even the scrolled offscreen elements consume rendering time?
If the latter, it would probably suffice to mark all elements
"don't render" except for the one containing the current frame.
That is essentially what SVG animation does, as I understand it,
so maybe it would in fact be acceptably fast. 

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

Neither.  Gnuplot has an event loop that receives mouse events from the
window manager and from the relevant graphics subsystem.

I imagine that at least for the qt flavor of domterm I could figure out
how to enable generation of mouse events from Qt.  We already do that for
the Qt terminal. The problem would be initial calibration of
the mapping from raw mouse pixels to the corresponding x/y offset in
pixels from the plot origin.  That part requires cooperation between
the gnuplot terminal driver and the terminal it talks to.
I.e. when gnuplot initializes a new plot, there needs to be some way
for the terminal to feed back "I put the lower left corner of your
plot at raw mouse coords x0/y0 and the upper right corner at raw mouse
coords x1/y1". 

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

		cheers,
			Ethan