Re: gplt_x11 ignores SIGINT and SIGTSTP. Why?

[Ethan A M. <me...@uw...>]

On Thursday, 1 September 2022 17:22:37 PDT Dima Kogan wrote:
> Hi Ethan.
> 
> 
> Ethan A Merritt <me...@uw...> writes:
> 
> > On Thursday, 1 September 2022 00:12:01 PDT Dima Kogan wrote:
> >>
> >> I'm looking at patching gplt_x11.c to work better with existing X window
> >> IDs. This is coming along. In the process I'm discovering other things.
> >> One is that for some reason the gnuplot x11 backend is explicitly
> >> ignoring the SIGINT and SIGTSTP signals:
> >
> > I do not recall, or never knew, those details. But I would imagine
> > that it ignores SIGTSTP because backgrounding gnuplot_x11 would be a
> > bad idea - it would stop responding to new commands from the main
> > gnuplot process.
> 
> I suspected this predates you. It feels like an odd thing to do to
> specifically mask out SIGTSTP, but I guess that's fine. Masking out
> SIGINT creates zombies, though, so there's a clear downside. 

Again only guessing, but I wonder if some window managers send SIGINT
to the controlling process (or did back in the day) when a window is
forcibly closed. 

> I can try to keep SIGINT only, and dogfood that change in my everyday
> usage (I make a LOT of plots). If I don't find anything obviously broken
> as a result after a few weeks, can we merge it?

You make a lot of plots but presumably they are all made from the
same environment.  My concern would be that it breaks some other 
window manager or desktop or OS or X-server etc...

... Hang on a minute, when you say "keep SIGINT only" do you mean keep the
SIGINT handling as it is (masked) or do you mean keep (as in "not block")
SIGINT?
 
> > It's been too many years since I was seriously using or looking at the 
> > x11 terminal driver.  I think the world has moved on from direct use
> > of Xlib to drive graphics output, in favor of higher level libraries.
> 
> One could say that the world has moved on from gnuplot too, yet here we
> are. For my own interactive use I use the x11 terminal exclusively. I
> find it to be dramatically faster than both qt and wxt. Doubly so if
> x-forwarding (the world is in the process of moving on from X, but it's
> not clear if it will ever get there). Yes, the x11 terminal doesn't do
> anti-aliasing or transparency or fancy text like qt and wxt do, but I've
> never felt like I missed those features in my usage.

If by "fancy text" you mean the text mark-up, it does support that.
The bigger issue is that it doesn't handle UTF8 [*].
X11 and PostScript were state of the art back when gnuplot was new,
but they both suffer from the same myopic view characteristic of
that era: "256 characters are enough".

 > In my mind, one big argument for gnuplot in general, as compared to
> other plotting libraries, is its speed. Using a non-x11 terminal dulls
> that argument.

I think we had this discussion about 10 years ago :-)
   https://sourceforge.net/p/gnuplot/mailman/message/30718556/

At the time there was at least one plot type (3D images)
for which x11 was faster, but I do not think that is true today.

It's been a while since I did extensive benchmarking, but here's a
quick timing run on my home desktop:

[~/temp] setenv GNUTERM x11 ; time gnuplot all.dem < /bin/yes >& /dev/null
14.931u 3.520s 0:52.84 34.9%    0+0k 8+0io 0pf+0w
[~/temp] setenv GNUTERM qt ; time gnuplot all.dem < /bin/yes > & /dev/null
13.143u 2.276s 0:21.02 73.3%    0+0k 0+0io 0pf+0w
[~/temp] setenv GNUTERM wxt ; time gnuplot all.dem < /bin/yes > & /dev/null
40.824u 4.306s 0:48.56 92.9%    0+0k 4328+0io 1008pf+0w

Both wxt and qt are faster than x11 (clock time).
qt is impressively faster - the test run completes in less
than half the time used by x11.

Note that the 'u' and 's' times for wxt are for a single process
while those for x11 and qt are for the inboard (gnuplot) process only.
But qt is faster than x11 by that measure also.

Also note that there are some compute-heavy demos in that test set.
If I were to limit it to the ones that are more purely graphics
then the speed difference would be even more noticeable in favor of qt.
 
>
> [Large snip that I may get back to later]
>

> Let's say the request was "I want a gnuplot-powered plotting widget in
> my GTK application". What would you suggest in that case?

Isn't that what wxt is? 
On linux anyway.
The OSX version of wxt uses a different, non-GTK, back end by default;
I do not know if you can persuade it to use GTK there instead.

	Ethan

[*] Long ago I managed to get x11 to more or less handle UTF8 by
using multi-font support and encoding ISO10646 for the x11 fonts.
The scripts I used then no longer work, and I can't be bothered
to figure out how or if it can be made to work again now.