[Octave-bug-tracker] [bug #61259] slow printing of images

[Pantxo Diribarne]

Update of bug #61259 (project octave):

                  Status:                    None => Need Info              

    _______________________________________________________

Follow-up Comment #3:

When a figure has been created by a given graphics toolkit you must specify
its handle to the "graphics_toolkit" function in order to have it redrawn by
the requested tookit, i.e., in your example, you should have "graphics_toolkit
(1, agt{k});"

This should change your numbers, i.e. :
* gnuplot should have very different timings than other tookits,
* for "qt" toolkit raster images (png here) will be much faster for large
point numbers.

Does it?

Now for vector formats (pdf here) with qt/fltk toolkits, Octave doesn't do any
filtering to data before printing and gl2ps (which is behind the `painters`
printing renderer) thus has to retrieve/parse/sort/print as may point
coordinates as the axes object contains. The timings should be proportional to
the point number, until you reach the default data buffer size... As you
noted, with large point numbers you'll exceed the default size and Octave will
try again with a buffer twice as large, which may not be enough...

So finally, if you can live with raster images, and "qt" toolkit (the default)
fits your needs you should choose this solution.
Otherwise, you'll have to decimate data before printing.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?61259>

_______________________________________________
  Message posté via Savannah
  https://savannah.gnu.org/