#1842 clean up SVG terminal and add support for DomTerm embedding

[Per Bothner]

The DomTerm terminal emulator lets you embed SVG (and clean HTML) directly "at the cursor", which makes for a very nice gnuplot UI. See a screenhot along with some background and links
http://per.bothner.com/blog/2016/gnuplot-in-domterm/

The patch also fixes a pre-existing problem when setting term to svg without re-direction. In that case you get weird incomplete interleaving of svg and text (commands).

This patch does not support multiplot for DomTerm - though it does not break multiplot when output is redirected. If there is interest, I have an idea for handling multiplot by adding to an existing svg element - though that requires some changes to DomTerm as well as gnuplot.

It would be better to be able to just "set term domterm" instead of "set term svg domterm", but that is a biggger change which I hven't looked into (though I'd be happy to).

[Ethan Merritt]

I wanted to try this out myself, but I could not build DomTerm on my current linux boxes. Guess I'll have to wait for inclusion of libqt5webengine in the Mageia 6 beta due out in a month or so.

So meanwhile I'm commenting based just on reading the code.

1) I think you have misunderstood the interaction between multiplot and term->graphics() || term->text(). It's fine to break out some of the initialization code into a new routine SVG_write_preamble(), but this should always be called by term->init() and not from term->graphics(). The multiplot flag has nothing to do with this that I can see. If the DomTerm code needs a separate set of conditions for writing the preamble, fine, but that should not involve the multiplot flag.

2) Same thing for involving multiplot tests in SVG_reset(). That's not correct. It should always finish up the output stream regardless of multiplot status. I can understand that DomTerm requires sending "" in term->text() but again that has nothing to do with multiplot.

3) There is no way to undo your new flag "nodoctype". Either there needs to be a corresponding "doctype" flag (seems ugly) or else it should get cleared by default by "set term svg".

General question about DomTerm - can it handle HTML5 canvas graphics? If so, would the ultimate goal be to have a gnuplot terminal "set term domterm {svg|canvas|...}" ?

[Per Bothner]

I'll look at your techinical comments shortly, but firest a partial response.

(0) qtwebengine is only needed for the qtdomterm application. If you have OpenJDK and Firefox, you should be able to configure with default flags, make, and then just run the bin/domterm script. For more details see the Applications page. (Note: I will probably split this into multiple pages soon.)

(3) I agree there doesn't seem to be any use for a separate nodoctype option. It is useful to have a
SVG_emit_doctype variable that is reset by the "domterm" option, but (at this point) there is no usecase for a user-visable separate option.

(Canvas question) DomTerm could in principle handle HTML5 canvas. The question is how best to expose it to applications. Loading JavaScript in the browser engine is possible, but there are security concerns to consider. (Using an <iframe> may help.) My preferred model is for the application to send escape sequences, which would be interpreted by DomTerm's pre-installed JavaScript. However, that requires defining and implementing an escape sequence format. Maybe we can find some existing format.</p> <p>Also consider being able to save the DomTerm state as a nice offline-viewable html page. (Not implemented, but a feature I'm planning.) SVG representation of the plots would preferable to exporting a canvas to a PNG file.</p></iframe>

[Ethan Merritt]

I am confused. Yes, I was trying to build the qtdomterm application. That was, I thought, the whole point. Guess I missed something.

What is the use case for domterm running in a normal web browser?
I can already display gnuplot output in a web browser just fine. For that matter you can use emscripten to run all of gnuplot in a web browser with svg display back to that same browser (see http://gnuplot.respawned.com/).

[Ethan Merritt]

If you have OpenJDK and Firefox, you should be able to configure with default flags,
make, and then just run the bin/domterm script.

That doesn't seem to work.
Default configuration fails on a bunch of java stuff that I don't have. I do have java-1.8.0-openjdk installed, but apparently that is not sufficient.
./configure --without-java gets further but then fails because it can't find libqtwebengine.

Any hints?

[Per Bothner]

The bin/domscript script does not "run DomTerm is a normal web browser". It starts up a full-featured terminal emulator (you can run emacs and mc with colors and mouse support), just like the qtdomterm application, that looks and acts like a regular terminal emulator - except it has the DomTerm goodies such as "printing" graphics.

The implementation of the bin/domterm script calls firefox in "app" mode, with a custom XUL wrapper.

Even if you run domterm is a regular browser (which is another option), the benefit is you have the gnuplot output integrated and interleaved in the same window as your terminal-style interactions.

[Per Bothner]

"Default configuration fails on a bunch of java stuff that I don't have. I do have java-1.8.0-openjdk installed, but apparently that is not sufficient."

It should be enough. There might be a bug in the configuration script or Makefile. Could you be more specific about how it fails?

[Per Bothner]

Hm. There is a configure script bug - it tris building qtdomterm. Try 'make libpty.so domterm.jar' until I fix it.

[Per Bothner]

Arg. Someting else seems broken with bin/domterm. Hold on ...

[Per Bothner]

You should be able to:
./configure --without-qtwebengine
make
bin/domterm
as long as java, javah, and javac are in your PATH.

I was confused because running multiple instances of bin/domterm at the same time doesn't work because of the way Firefox handles "apps".

[Ethan Merritt]

build failure:

In file included from native/pty/pty.c:33:0:
native/pty/org_domterm_pty_PTY.h:2:17: fatal error: jni.h: No such file or directory
 #include <jni.h>
                 ^
compilation terminated.
Makefile:26: recipe for target 'native/pty/pty.o' failed

[Per Bothner]

jni.h should have been installed as part of OpenJDK - as long as you have javac and the other Java developer tools. I.e. if you have javac you should have jni.h.

So the issue is why are we not finding it. The configure script tries to set JAVA_HOME such that $JAVA_HOME/include contains jni.h. If JAVA_HOME isn't already set in the environment, then the configure script tried to deduce JAVA_HOME based on the location of javac. For me it works for both the Fedora OpenJDK package, or if I uses Oracle's Java SE. However, Megeia may have a different setup where that doesn't work.

[Ethan Merritt]

OK. So this works:
unsetenv JAVA_HOME
./configure --without-qtwebengine
make

and.... got it.

I ran through all the demos

1) layout.dem and other multiplot demos work as expected. What did you mean about multiplot not working?
2) The "fit" demo are ridiculously slow, execution time in minutes rather than a fraction of a second. The fit is a purely numerical computation and nothing to do the display, so why would running it in DomTerm make it slow down? Firefox shows as consuming 100% CPU while this is going on.
3) The 3D demos are also slow, although not as bad as the "fit" demos.
4) By contrast "nonlinear3.dem" runs relatively quickly. That should be a more severe test of both computation and rendering time. So what's going on?
5) A few of the plots, like the fence plot demo in surface1.dem come out with the wrong colors.
6) [this is a bad one] After I exit gnuplot, firefox hangs around eating 100% CPU time. I had to kill it externally.

So overall promising, but firefox performance seems to kill this variant of DomTerm. I find it very strange that the worst performance is during demos that don't even have graphical output. That is probably a big clue to something or other.

I look forward to trying with the Qt version of DomTerm.

Please revise the patch to remove all the "multiplot" special case handling. I really don't think it is relevant.

[Per Bothner]

"5) A few of the plots, like the fence plot demo in surface1.dem come out with the wrong colors."

This appears to be a pre-existing gnuplot bug, not relating to either DomTerm, or my patch

[Per Bothner]

"1) layout.dem and other multiplot demos work as expected. What did you mean about multiplot not working?"

Multiplot of the incremental/updating kind doesn't work.

http://gnuplot.sourceforge.net/docs_4.2/node203.html states:
"For some terminals, no plot is displayed until the command unset multiplot is given, which causes the entire page to be drawn and then returns gnuplot to its normal single-plot mode. For other terminals, each separate plot command produces an updated display, either by redrawing all previous ones and the newly added plot, or by just adding the new plot to the existing display. "

The domterm support is currently in the former category. It is definitely possible to do the latter, but inserting new svg "commands" inside an exising svg element. That requires some new functionality in DomTerm, though I don't expect it to be very difficult.

[Per Bothner]

I updated my patch. I ceated a separate "domterm" terminal type, and there is no longer a "domterm" option to the "svg" terminal type.

With ihis patch, I believe there are no detectable changs to the "svg" terminal. However, there probably should be. There is at least one bug: The header <g id=\"gnuplot_canvas\" is written by SVG_init (when SVG_domterm is not set), but the matching </g> is written in SVG_text, so you get mismatched tags. Either the start tag should be moved to SVG_graphics or the close tag should be moved to SVG_reset.

There is also the more fundamental problem that the <\svg> close tag isn't written until SVG_reset, which means that until that happens you have mismatching output. The question is what is the desired result when writing mutiple plots. Currenty, they're all appended to the same <svg> element, which means you get an unreadable mess. Alternatively, each plot could generate a separate <svg> element. That would not result in a a valid SVG file. However, we could instead create an html file that contains multiple <svg> elements inside a toplevel <html> or <body> element.

[Per Bothner]

Some other notes (in adition to the updated patch in the prevous message):

The configure script tests that $JAVA_HOME/bin/javac exists so you shouldn't have to explicitly unset it.

The configure default was fixed to --without-qtwebengine.

Firefox is indeed very slow. I'm looking into some optimization of the JavaScript code. Most critically, checking for line-breaking lazily. I don't yet know how much that will help with gnuplot, but it will almost certainly speed up other things (such as cat-ing large files), so it is desirable anyway.

Until then, you can use a feature I added to make it easy to use your browser of choice:

bin/domterm --browser[=PROGRAM]

This will start a shell in a pty, and then create a fresh window/tab in the browser specified by PROGRAM (which defaults to your default desktop browser), using WebSockets to connect them.

PROGRAM can be any modern browser that has WebSockets suppport (for example --browser=google-chrome). It just needs to take a single argument, a file: URL.

You can also run:

bin/domterm --chrome

That runs "google-chrome" with the "--app" option.

[Per Bothner]

I checked iDomTerm changes that should make FireFox a lot faster. Basically, I used the JavaScript requestAnimationFrame to delay some expense re-calcalculation. Made a big difference. It also helped Chrome with some things. (Cat-int a big file used to be painfully slow - on Chrome or Firefix, but is now quite fast.)

I also chcked in a "Save As" feature, which was the console "log" as HTML viewable in "any" modern browser. The SVG plots are included. See http://domterm.org/Tips.html for more about this, including how to set up stylesheets for the saved file.

[Ethan Merritt]

Accepted into CVS for version 5.1

[Per Bothner]

Thanks!