Re: gnuplot image code

[Quentin Spencer]

John W. Eaton wrote:
> On 20-Oct-2006, Quentin Spencer wrote:
>
> | function version = __gnuplot_version__
> | 
> |   persistent __version__ = 0;
> | 
> |   if !__version__
> |     ## If the function hasn't been called before, use this code to get
> |     ## the version from gnuplot.
>
> What should happen if gnuplot_binary is called to specify a different
> version of Octave?  Should we expect that to work without restarting
> Octave?
>   

Good point. I assumed it was something that would not likely be changed 
during an octave session, and that calling gnuplot just to get the 
version would be slow and undesirable to repeat. However, I suppose 
plotting is not ususally done in speed critical sections of code, so 
maybe this isn't necessary.

> |   ## Gnuplot reads binary files very quickly.  However, the 'fwrite' below
> |   ## is much slower than using the current '__gnuplot_plot__' command.
> |   fwrite(fid, A', "float", 0, "ieee-le");
>
> Octave's fwrite function was written to handle skip, but it is not
> done very efficiently, and the simple case of writing contiguous
> blocks of data with one function call is not done at all (I was more
> concerned with handling skip correctly).  If someone would like to
> work on this project, the place to start is the function
>
>   template <class T>
>   octave_idx_type
>   octave_stream::write (const Array<T>& data, octave_idx_type block_size,
>                         oct_data_conv::data_type output_type,
>                         octave_idx_type skip, oct_mach_info::float_format 
> flt_fmt)
>
> in src/oct-stream.cc.
>
> Also, why not just write in the native format?
>   

By native format, you mean the text format that is normally used for 
communicating with gnuplot? I suppose that could be done, but eventually 
when gnuplot 4.2 is widely used, I think it would be good for octave to 
use the binary format because it will be noticeably faster for large 
data sets.

Quentin