Wed 06 Dec 2017 10:00:23 AM UTC, comment #14:
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.
|
Tue 05 Dec 2017 06:45:20 PM UTC, comment #13:
Rik: octave ver was current dev.
|
Tue 05 Dec 2017 06:37:44 PM UTC, comment #12:
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.16-302.fc27.x86_64 #1 SMP Thu Nov 30 15:33:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
|
Tue 05 Dec 2017 06:28:18 PM UTC, comment #11:
I'm running KDE. I tried turning off anti-aliasing 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)
|
Tue 05 Dec 2017 06:08:18 PM UTC, comment #10:
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.
--
|
Tue 05 Dec 2017 06:05:59 PM UTC, comment #9:
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 anti-aliasing settings
would affect qt backend but not fltk. (I am on gnome).
Note i also timed .eps file to avoid ghostscript involvement.
Dmitri.
|
Tue 05 Dec 2017 06:00:16 PM UTC, comment #8:
@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.
|
Tue 05 Dec 2017 05:03:29 PM UTC, comment #7:
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.
--
|
Tue 05 Dec 2017 04:42:33 PM UTC, comment #6:
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 m-file as tst_slowprint.m.
(file #42573)
|
Tue 05 Dec 2017 03:51:51 PM UTC, comment #5:
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.
|
Tue 05 Dec 2017 10:10:07 AM UTC, comment #4:
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".
|
Tue 05 Dec 2017 05:05:43 AM UTC, comment #3:
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.
--
|
Tue 05 Dec 2017 04:38:28 AM UTC, comment #2:
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.
|
Mon 04 Dec 2017 07:13:15 PM UTC, comment #1:
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.
|
Mon 04 Dec 2017 04:59:33 PM UTC, original submission:
Doing
using the attached file foo.ot, makes octave hang.
|