PLplot

Jay Christnach writes:
 > hello again!
 > to answer my previous question:
 > My 50 channel oscilloscope application is feasible with plplot as graph 
 > library. It is really fast. I use the polygon fill function to erase previous 
 > plotted data.
 > 
 > but another problem:
 > If I let the program run a long time my hard disk fills up. It took some time 
 > to find out what file would get so huge, because the file doesn't show up in 
 > the filesystem, because it is already deleted. (funny phenomenon). 
 > #lsof -c scope
 > COMMAND   PID USER   FD   TYPE     DEVICE       SIZE    NODE NAME
 > (...)
 > scope   32031 root    6u   REG        8,3 1415630848   19684 /tmp/tmpfXiOQuk 
 > (deleted)

Heh.  That looks like the plot buffer.  As you create a plot under X, the plot
buffer pseudo-device is written to, so that on window expose or redraw events,
the prior contents of the window can be recovered.  It's closed at every
end-of-page, and my guess is that you aren't issuing any.. LOL.  There really
should be a size limitation on it though.. >1G is way, way too big. :)

Although there is no API control for this, fortunately you do have access
through the plplot stream pointer.  You can disable writing to the plot buffer
entirely by setting pls->plbuf_write to 0.  Or keep it writing by default but
control its contents through manipulating pls->plbufFile.  See src/plbuf.c for
more info.

-- 
Maurice LeBrun

Jay Christnach wrote:
> 
> hello again!
> to answer my previous question:
> My 50 channel oscilloscope application is feasible with plplot as graph
> library. It is really fast. I use the polygon fill function to erase previous
> plotted data.
> 
> but another problem:
> If I let the program run a long time my hard disk fills up. It took some time
> to find out what file would get so huge, because the file doesn't show up in
> the filesystem, because it is already deleted. (funny phenomenon).
> #lsof -c scope
> COMMAND   PID USER   FD   TYPE     DEVICE       SIZE    NODE NAME
> (...)
> scope   32031 root    6u   REG        8,3 1415630848   19684 /tmp/tmpfXiOQuk
> (deleted)
> 
> I suspect that pouring that many data so fast into the X-server or the plplot
> device perhaps causes it to build up a queue which grows ever bigger. But
> however my application runs normally and everything I want it to draw gets
> drawn even after the disk is saturated.
> 
> So where does the tempfile come from, why is it deleted (it immediately goes
> away when the program exits) and what exactly is its purpose? How could I
> correct this?
> 

PLplot uses a temporary file to store the plotting commands in. This is
used to recreate the image when necessary, but of course, in your case,
the whole history is stored ... That is an unforeseen consequence. 

I have no solution right now. Perhaps it is possible to turn off the
temporary file - you do not really need it. But you would have to
check the code.

Regards,

Arjen

On Thursday 15 January 2004 10:27, Maurice LeBrun wrote:
> Heh.  That looks like the plot buffer.  As you create a plot under X, the
> plot buffer pseudo-device is written to, so that on window expose or redraw
> events, the prior contents of the window can be recovered.  It's closed at
> every end-of-page, and my guess is that you aren't issuing any.. LOL. 
> There really should be a size limitation on it though.. >1G is way, way too
> big. :)
>
> Although there is no API control for this, fortunately you do have access
> through the plplot stream pointer.  You can disable writing to the plot
> buffer entirely by setting pls->plbuf_write to 0.  Or keep it writing by
> default but control its contents through manipulating pls->plbufFile.  See
> src/plbuf.c for more info.

(I'm really impressed by the speed one gets answers from this mailing list, 
Thanks!)

This got a bit complicated, because I'm no experienced C-programmer. 
Fortunately one knows somebody who knows more. We found that pls was declared 
static, so inaccessible and out of pure intuition we decided to try out plsc 
which is also a PLStream. And it worked! The temporary file is now still 
open, but it doesn't grow anymore. 
Here is what I did in my application code:
...
#include "plstrm.h"
extern PLStream *plsc;
....
plinit();
plsc->plbuf_write=0;
....

I'm not sure if this was the right (or the best) way to do it, but I think I 
can be happy with it. Thanks to the developers of those cool libraries which 
make programming a lot more fun!

The next challenge will be user interaction for which I will need an 
eventhandler for our window. Just don't know yet how to accomplish this 
stuff.

Best regards,
Jay

Jay Christnach wrote:
> 

> 
> This got a bit complicated, because I'm no experienced C-programmer.
> Fortunately one knows somebody who knows more. We found that pls was declared
> static, so inaccessible and out of pure intuition we decided to try out plsc
> which is also a PLStream. And it worked! The temporary file is now still
> open, but it doesn't grow anymore.
> Here is what I did in my application code:
> ...
> #include "plstrm.h"
> extern PLStream *plsc;
> ....
> plinit();
> plsc->plbuf_write=0;
> ....
> 
> I'm not sure if this was the right (or the best) way to do it, but I think I
> can be happy with it. Thanks to the developers of those cool libraries which
> make programming a lot more fun!
> 

I ran into a similar problem - and used the same solution. This had to 
do with PLplot being a library inside a larger application. 

> The next challenge will be user interaction for which I will need an
> eventhandler for our window. Just don't know yet how to accomplish this
> stuff.
> 

You might want to look at the Tcl/Tk binding: with Tcl/Tk you can easily
create user-interfaces and PLplot can serve to produce your graphical
display.

If you choose another solution, you will probably run into the problems
I referred to - I still have to commit them to the PLplot development
team - as they arose in this larger program, because it handles the
user-interface (and all window events) and uses PLplot as a graphics
library.

Regards,

Arjen

On Thursday 15 January 2004 09:27, Maurice LeBrun wrote:
|  Jay Christnach writes:
|   > hello again!
|   > to answer my previous question:
|   > My 50 channel oscilloscope application is feasible with plplot as graph
|   > library. It is really fast. I use the polygon fill function to erase
|   > previous plotted data.
|   >
|   > but another problem:
|   > If I let the program run a long time my hard disk fills up. It took
|   > some time to find out what file would get so huge, because the file
|   > doesn't show up in the filesystem, because it is already deleted.
|   > (funny phenomenon). #lsof -c scope
|   > COMMAND   PID USER   FD   TYPE     DEVICE       SIZE    NODE NAME
|   > (...)
|   > scope   32031 root    6u   REG        8,3 1415630848   19684
|   > /tmp/tmpfXiOQuk (deleted)
|
|  Heh.  That looks like the plot buffer.  As you create a plot under X, the
| plot buffer pseudo-device is written to, so that on window expose or redraw
| events, the prior contents of the window can be recovered.  It's closed at
| every end-of-page, and my guess is that you aren't issuing any.. LOL. 
| There really should be a size limitation on it though.. >1G is way, way too
| big. :)
|
|  Although there is no API control for this, fortunately you do have access
|  through the plplot stream pointer.  You can disable writing to the plot
| buffer entirely by setting pls->plbuf_write to 0.  Or keep it writing by
| default but control its contents through manipulating pls->plbufFile.  See
| src/plbuf.c for more info.

If using the xwin driver, you can use the "-drvopt nobuffered" cmd line driver 
option. Programatically, use plSetOpt("drvopt","nobuffered")

Joao

Jay Christnach writes:
 > Here is what I did in my application code:
 > ...
 > #include "plstrm.h"
 > extern PLStream *plsc;
 > ....
 > plinit();
 > plsc->plbuf_write=0;
 > ....
 > 
 > I'm not sure if this was the right (or the best) way to do it, but I think I 
 > can be happy with it. Thanks to the developers of those cool libraries which 
 > make programming a lot more fun!

Actually, it would be a bit better to use plgpls() to get the stream pointer.
That way it would still work should you ever go with multiple streams, or if
we should ever make plsc unavailable to the outside world.  While plgpls() is
not part of the "common" API, it is still part of the standard "C" API AFAIAC.

-- 
Maurice LeBrun