This design is
specifically what we're trying to avoid because of efficiency reasons.
Data transfer efficiency?
Data transfer efficiency. In process terminals do not need to transfer any data.
Or memory space efficiency? I've tested the gnuplot demos and they are fairly snappy. None of the terminals approach that of X11, but Qt is pretty close. For very large polygon drawing it is slow. However, the reason it may be slower than X11 is that I suspect it is doing more in terms of antialiasing of fonts and lines.
Qt painting engine is quite efficient. I suspect it's due more to data transfer over UNIX socket.
So communications from gnuplot to the Qt terminal doesn't seem critical. But we know the pipe from Octave to gnuplot can be slow for large data sets.
Data transfer between gnuplot and its Qt terminal will be equally slow .
Note also that the gnuplot implementation is based on "fork", so it's
not portable to native Windows.
Well, I do see in the code that fork() is used when the technique that uses qt_socket.connectToServer(server) fails.
I don't think that's how it works. My understanding is that there will be only one Qt plotting server instance. So it first checks whether an instance is running, otherwise it creates it. But in all case, fork() will be called at least once.
Michael.