[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: handle graphics
Re: handle graphics
Sat, 16 Jul 2005 15:30:44 +0200
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
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 &
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!
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
Re: handle graphics, jswensen, 2005/07/13
- Re: handle graphics, (continued)
- Re: handle graphics, John W. Eaton, 2005/07/13
- Re: handle graphics, Jonathan Stickel, 2005/07/13
- Re: handle graphics, Ole Jacob Hagen, 2005/07/13
- Re: handle graphics, jswensen, 2005/07/13
- Re: handle graphics, Bill Denney, 2005/07/13
- Re: handle graphics, Shai Ayal, 2005/07/14
- Re: handle graphics, John W. Eaton, 2005/07/14
- Re: handle graphics, Shai Ayal, 2005/07/15
- Re: handle graphics, Paul Thomas, 2005/07/15
- Re: handle graphics, Paul Kienzle, 2005/07/15
- Re: handle graphics,
Shai Ayal <=
- Re: handle graphics, Ole Jacob Hagen, 2005/07/17
- Re: handle graphics, Daniel J Sebald, 2005/07/13