Re: tmp gets full when plotting many images

[John W. Eaton]

On 26-Mar-2007, Daniel J Sebald wrote:

| John W. Eaton wrote:
| > On 26-Mar-2007, Daniel J Sebald wrote:
| > 
| > | This could be improved perhaps by utilizing the fact that data through 
the pipe 
| > | can now also be binary.  (I doubt there are any pipes out there that 
restrict 
| > | data to 7 bits, ASCII, rather than 8 bits.)  Let me know if you want to 
try this 
| > | approach.
| > 
| > I think it would be best if we can avoid the temporary files for image
| > data.  Can we do the same for the palette data?
| 
| Sure, if I remember correctly, there is a conditional test in the current 
Octave 
| __go_draw_now__ code that checks the length of the palette.  If it gets very 
| long, then it too uses a datafile.  So, simply modify that condition test to 
| remove the path using data files.

I started doing that, but then I realized that I don't understand why
the first case has 4 columns and the second only three.

  if (palette_size <= 128)
    ## Break up command to avoid buffer overflow.
    fprintf (plot_stream, "set palette file \"-\" using 1:2:3:4;\n");
    for i = 1:palette_size
      fprintf (plot_stream, "%g %g %g %g;\n",
               1e-3*round (1e3*[(i-1)/(palette_size-1), img_colormap(i,:)]));
    endfor
    fprintf (plot_stream, "e;\n");
  else
    ## Let the file be deleted when Octave exits or
    ## `purge_tmp_files' is called.
    [cmap_fid, cmap_fname, msg] = mkstemp (fullfile (P_tmpdir, 
"gpimageXXXXXX"), 1);
    fwrite (cmap_fid, img_colormap', "float32", 0, "ieee-le");
    fclose (cmap_fid);
    fprintf (plot_stream,
             "set palette file \"%s\" binary record=%d using 1:2:3;\n",
             cmap_fname, palette_size);
  endif

| Would you like to always use binary data through the pipe?  (It's been tested 
| pretty thoroughly, but trying something new is always a bit dodgy.)  There is 
| generally a noticeable difference between binary data and formated I/O.

Let's leave the line and surface data in text for now.

jwe