Re: handle graphics

[Shai Ayal]

In any case (threads or not) a two way protocol should be established
& DOCUMENTED so that people can start writing graphic fronts.

The handle graphics structure should be 
1. unique 
2. global
3. read only as a structure, i.e. everyone should be able to do
"fieldnames(figure)", but not figure.axes = 15;
4. changeable only the "set" command which will also to all the type &
consistency checks.

It seems to me that 1 & 3 cannot be achieved using the interpreter
alone. Once they are done using c++, 2 is trivial and 4 can be done
using m-files. So we do need a new custom type which gives us 1 & 3,
but from the examples I have seen already (CMO & oplot) this seems to
be doable. As I noted before the bulk of the work is 4!

Shai

On 7/16/05, Paul Kienzle <address@hidden> wrote:
> There were some issues I had four years ago in which the X server would
> give strange errors if the oct-file was compiled with threads but
> octave was not.  IIRC, it had something to do with whether the C
> library was compiled with threads.  This may not be relevant today, but
> it is something to watch out for when you are experimenting.  See the
> crufty code in octave-forge/extra/tk_octave for an example.  Note
> though that this code does not handle memory in a thread-safe manner.
> 
> I would argue for threads over shared memory for much the reason Paul T
> gives below, with the added advantage that it will work natively in
> Windows without cygwin.
> 
> - Paul
> 
> On Jul 15, 2005, at 4:44 PM, Paul Thomas wrote:
> 
> > Shai,
> >
> >> of data to be plotted. Shared memory seems the most natural, but I'm
> >> not sure it quite works on cygwin.
> >>
> > It works fine, as long as the required services are up and running.
> > This is not the default but can easily be added to profile files.
> > There is quite a lot about this in the Cygwin documentation.
> >
> > I wonder if threads would not be better?  Thread safeness is not a
> > problem, if each thread uses a different io resource.  If the octave
> > thread holds the console window and each other thread a different
> > graphics window, things should run smoothly.  The common memory and
> > signalling is a matter of design but would not be different to shared
> > memory.  Since the system overheads are less, threads should offer a
> > performance advantage.
> >
> > Paul T
> >
> >
> 
>