From octave-maintainers-request at bevo dot che dot wisc dot edu Tue Nov 11 00:49:37 2003
Subject: Re: Shared memory interface to Octave
From: pkienzle at users dot sourceforge dot net
To: N Smethurst <nick dot smethurst at free dot fr>,    <octave-maintainers@bevo.che.wisc.edu>, <jswensen@intergate.com>
Date: Tue, 11 Nov 2003 01:51:34 -0000

On 10 Nov 2003 at 17:08, N Smethurst wrote:

> Hi John
> 
> I've been using sockets in my application (kvisualiser.free.fr). I've found it 
> generally takes only about 10-15ms to base64 encode in XML, transfer, and 
> then decode a 150x150 point polydata surface (703KB including base64 
> encoding). Admitedly this is on an Athlon 1400. However, the amount of data 
> for a GUI would generally be far less than this, so I would imagine that the 
> resulting time lag would be negligible.

Perhaps there is something wrong in my implementation of 
TCP/IP sockets, or Tcl's implementation, or maybe its just
that my 300 MHz machine is slow, but I find a 40 ms round
trip time to send a message from Tcl to Octave whose content
is to send a message from Octave to Tcl (up to 80 ms on
Windows 2000).  This is generally fast enough for
interactive behaviour, assuming there is only one callback
per mouse event, but you would definitely want to keep
this sort of code out of a tight loop (e.g., a fit update routine).

> Out of interest, what kind of application are you aiming to write? I was 
> invisaging starting at some point a front end to Octave as a companion to 
> KVisualiser. If our ideas were similar, perhaps there could be a 
> collaboration.

The trick with any sophisticated scientific visualiser is that the
user will want to be able to interact with the graph and send
information back to the calling program.  For example, a
collegue is writing a peak fitting module.   He wants
to be able to click on the curve at half max and drag the
mouse to the peak, resulting in an approximate gaussian
which he can then refine either by clicking and dragging the
center and height or the middle and width.  If necessary,
he wants to use an optimizer to get a more precise fit and
an estimate of the uncertainty in the peak parameters.

The user should also have available a wide array of user interface
widgets, so that for example he can write things like the
matlab auditory demo to help his students understand 
speech processing:

http://www.dcs.shef.ac.uk/research/groups/spandh/MAD/docs/mad.htm

You know you are on the right track when you have something
sufficiently powerful to write an Octave front end directly in a
script.  If you can't, then your user interface controls aren't
good enough.  If you can, then you are wasting your time
trying to code directly in C in the underlying widget library.

Paul Kienzle
pkienzle at users dot sf dot net