Okay, everything seems to be explained and the performance is better for the original reporter. Marking bug as fixed and closing report.

I get timings of order 0.3 s with tst_slowprint2 for both fltk and Qt.
@Rik: the Qt toolkit now uses getframe instead of gl2ps to produce png outputs while fltk still uses gl2ps. Qt being much faster than fltk with tst_slowprint may just be an indication that painters (eps>png) is much slower than opengl (getframe) on your computer.

@pantxo: no slowdown for me anymore.

On my ancient Xeon (Fedora 29):
./runoctave qf
octave:1> graphics_toolkit
ans = qt
octave:2> tst_slowprint
Elapsed time is 0.799074 seconds.
octave:3> tst_slowprint
Elapsed time is 0.361146 seconds.
octave:4> tst_slowprint
Elapsed time is 0.359951 seconds.
./runoctave qf
octave:1> graphics_toolkit fltk
octave:2> tst_slowprint
Elapsed time is 1.15846 seconds.
octave:3> tst_slowprint
Elapsed time is 0.473205 seconds.
octave:4> tst_slowprint
Elapsed time is 0.455319 seconds.
===========
./runoctave qf
octave:1> graphics_toolkit qt
octave:2> tst_slowprint2
Elapsed time is 0.708672 seconds.
octave:3> tst_slowprint2
Elapsed time is 0.247001 seconds.
octave:4> tst_slowprint2
Elapsed time is 0.243794 seconds.
./runoctave qf
octave:1> graphics_toolkit fltk
octave:2> tst_slowprint2
Elapsed time is 0.967463 seconds.
octave:3> tst_slowprint2
Elapsed time is 0.231865 seconds.
octave:4> tst_slowprint2
Elapsed time is 0.231469 seconds.
_opengl_info_
version: 3.1 Mesa 18.2.4
vendor: VMware, Inc.
renderer: llvmpipe (LLVM 7.0, 128 bits)
Dmitri.


I still see a big difference between Qt and FLTK toolkits. I also have upgraded my physical hardware and my operating system since this bug was filed. I am running today's latest tip (11/6/18).
However, running tst_slowprint2 which doesn't involve ghostscript the times were about the same, but not exactly fast.

@muhali: Is this still an issue for you? I don't observe the slowdown anymore, but in the mean time I have changed my OS and driver.

I wonder what caused this behaviour. I don't think I saw it half a year ago, neither in stable nor in dev, with the same or similar data.

Rik: octave ver was current dev.

Rik: Relative fltk vs. qt seems to depend on the system.
[godfrey@pbdsl4 plot_timing]$ oct
octave:1> tst_slowprint2
Elapsed time is 2.48103 seconds.
octave:2> tst_slowprint
Elapsed time is 2.38323 seconds.
octave:3> graphics_toolkit
ans = fltk
octave:4> graphics_toolkit('qt')
octave:5> tst_slowprint2
Elapsed time is 2.26857 seconds.
octave:6> tst_slowprint
Elapsed time is 2.51041 seconds.
octave:7> graphics_toolkit
ans = qt
octave:8> quit
[godfrey@pbdsl4 plot_timing]$ uname a
Linux pbdsl4 4.13.16302.fc27.x86_64 #1 SMP Thu Nov 30 15:33:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

I'm running KDE. I tried turning off antialiasing with
but it made no difference. FLTK was just way slower than QT. I modified the test script to use eps so that there is no ghostscript involvement. I've uploaded that script as tst_slowprint2.m. This also made no difference on my system.
(file #42574)

Here are the times with the original data file:
octave:1> graphics_toolkit qt
octave:2> load foo.ot
octave:3> plot(u, F, ".") ;
octave:4> tic; print t1.eps; toc
Elapsed time is 8.83654 seconds.
octave:1> graphics_toolkit fltk
octave:2> load foo.ot
octave:3> plot(u, F, ".") ;
octave:4> tic; print t1.eps; toc
Elapsed time is 8.77279 seconds.
Dmitri.


I have similar results with the original (times about the same).
I wonder if the results are due to the environment.
Are you using KDE desktop? may be some antialiasing settings
would affect qt backend but not fltk. (I am on gnome).
Note i also timed .eps file to avoid ghostscript involvement.
Dmitri.

@Dmitri: Interesting. The original file had ~20,000 points. Maybe you could try adjusting the number of points to see if there are breakpoints, such as 1024, 4096, 8192, where the performance between FLTK and QT is different. That might be a clue to where the problem lies.

I get pretty much identical times:
octave:1> graphics_toolkit qt
octave:2> x = linspace (0,1, 1e3);
octave:3> plot (x,x, '.')
octave:4> tic; print t1.eps; toc
Elapsed time is 0.635007 seconds.
...
octave:1> graphics_toolkit fltk
octave:2> x = linspace (0,1, 1e3);
octave:3> plot (x,x, '.')
octave:4> tic; print t2.eps; toc
Elapsed time is 0.637315 seconds.
octave:5> _octave_config_info_ ("hg_id")
ans = 8b14ba8296af
Dmitri.


In order to make progress we probably need to go through the engineering cycle of design/build/test. And the number of iterations through that cycle is limited if it takes 15 minutes to test each new change.
A simpler example of the problem is
This takes 8 seconds on the development branch with FLTK, and 0.5 second with QT. I've attached the mfile as tst_slowprint.m.
(file #42573)

Interestingly, the performance is very dependent on the backend. With the qt backend, printing completes in 2.5 seconds. With the FLTK backend, printing takes 171 seconds. This was on the development branch with cset
I don't really understand why that would be since both qt and fltk rely on OpenGL underneath and gl2ps for printing.

I can confirm that printing with a large number of markers is very slow. On my computer though, with the address sanitizer enabled and debug symbols, the dev version is much slower than what you report: ~320s with either "o" or ".".
Unfortunately, each marker is drawn using a fixed number of lines, that depends on the marker type, and/or with an undefined (opengl driver dependent) number of triangles. With this approach, I can't see any easy improvement since gl2ps will always have to treat (eventual depth sort/write) each primitive.
Changing title to better describe the actual issue and changing status to "confirmed".

I guess I was impatient:
With dev:
octave:5> tic ; print t1.png ;toc
Elapsed time is 10.0654 seconds.
octave:6> tic ; print t1.eps ;toc
Elapsed time is 8.80283 seconds.
with 4.2.1:
octave:4> tic ; print t1.eps ;toc
Elapsed time is 472.672 seconds.
Dmitri.


This works for me, although I will say it is very, very slow.
That was with 4.2.1. On the development branch the time was 154 seconds which is still really long.

Confirm with 4.2.1 on Fedora 27
(also hangs printing to svg, eps).
Both qt and fltk are affected.
Works in a recent dev.
Dmitri.

Doing
using the attached file foo.ot, makes octave hang.
