I just want to point your attention to some detail of my original bug report (mostly in response to Rik's comment #6 ):

• The "slowness" is precisely the same for all THREE graphics backends, not only qt, also fltk and even the gnuplots backend is precisely as slow.

I have no clue at all of the implementation of Octave's graphics code. But doesn't the above fact suggest that the observed speed bottleneck is somewhere in a piece of code, that is common for all three backends? So I think this rules out the OpenGL code parts for example (because I assume they won't be used with graphics_toolkit gnuplot, would they?)

It seems that MATLAB has used the concept of nullable type.

From the documentation:


"An empty array in MATLAB is an array with at least one dimension length equal to zero. Empty arrays are useful for representing the concept of "nothing" programmatically."


All nonabstract MATLAB classes have a method named empty. For example we can write:

A = int16.empty(5,0);

It means that all non abstract types all nullable. Therefore we can make array of nulls and iterate over nulls.
--Interesting discussion--

@Markus, Rik: At least, Lachlan stated in bug #47052, that when creating line objects most of the time was spent initializing graphics_objects. A way to see that line objects rendering is quite fast is to try to use the "pan" tool on the figure:

tic; plot (1:1000, 10); toc ## -> 28s on my system

Panning is fast: I can't see jagged rendering which means that it doesn't take more than a few 10ms for each redraw.

On the contrary the example from bug #40663 is slow the first time (when creating patch objects) but also when panning

a = randn(1000,3);
scatter(a(:,1),a(:,2),[],a(:,3));

I was the one who checked in a partial fix for bug #47052.  That produced a 35% speed-up and the changes were only to m-files. 

You could benchmark it, or use the profiler, but my bet is that the problem now is in the call to _go_line_ which is from the m-file in to the C++ and further on in to the OpenGL renderer.

There is a similar report about scatter being slow and in that case it was definitively tracked down to the call to _go_patch_.

In summary, I think we need an OpenGL expert to give our code a review.  Plotting 1,000 points should be very, very fast.

This is definitely a task for the development branch.

@Pantxo: The results for your test code in Matlab:

>> x = 1:1000; % vector
y = 10;     % scalar
hlines = plot (x, y);
sprintf ('x,y-> %d line(s), marker ''%s''', numel (hlines), get (hlines(1), 'Marker'))

ans =

x,y-> 1000 line(s), marker 'none'

@Harmut: The expected behavior is properly documented in Matlab:

>> If one of X or Y is a scalar and the other is either a scalar or a vector, then the plot function plots discrete points. However, to see the points you must specify a marker symbol, for example, plot(X,Y,'o').

Now the question is whether Matlab creates as much line objects as the length of the vector (this is what Octave currently does, but much more slowly than acceptable), or if it simply creates one line with marker "none" (the equivalent of "plot (x, y*size (x), 'Marker', 'none')").

What does the following do in Matlab:

x = 1:1000; % vector
y = 10;     % scalar
hlines = plot (x, y);
sprintf ('x,y-> %d line(s), marker ''%s''', numel (hlines), get (hlines(1), 'Marker'))

If there is only one line then we can easily speed up this call form. Otherwise, we must stay ML compatible and we end up having to fix the very slow graphics_objects creation (known bug but I can't find the number ATM).

I just unintenionally noticed, that plotting a scalar value versus a vector takes incredibly long in Octave. Here is a small script to show what I mean:

close all

graphics_toolkit qt % fltk or gnuplot behave the very same

x = 1:1000; % vector
y = 10;     % scalar

tic
plot(x, y);
toc

First of all: I don't know if this usage of "plot(vector,scalar)" is documented at all. But it doesn't throw any errors, neither in Octave nor in Matlab.

Here are my timing results with the above script in Octave:

• Linux + Octave 4.4.1 (qt, fltk or gnuplot) -> 7 sec
• Linux + Octave 5.0.91 -> 7 sec
• Win 10 + Octave 4.4.1 (qt) -> 43 sec
• Win 10 + Octave 5.0.91 (qt, fltk or gnuplot) -> 50 sec

As a result Octave produces a plot window with 1000 differently colored little circles.

Here is the result of the above script in Matlab:

• Win 10 + Matlab (probably V2017b or V2018b) -> 0.5 sec

Matlab produces a totally emtpy plot window as result.

Argumentation:

In principle I like the current Octave behavior better than the Matlab one. This could be a nice "Octave only" feature. If someone (like me in this case) unintenionally plots only a single y value for a vector of x values it's quite obvious what should be plotted. And the resulting Octave plot is fine for this purpose.
But: It takes incredibly long until the final plot apprears in the window. I first did this under Windows 10, where it takes nearly a full minute! Meanwhile I had already Ctrl-C'ed the script and started searching of a bug somewhere. So in the current implementation, this "Octave only" feature is disturbing the user.

Possible solutions:

• (A) We could make this call to plot "illegal" and throw a (fast) error message. (But Matlab doesn't).
• (B) We could do the same as Matlab, and return an empty plot window.
• (C) We could speed up our Octave plotting code for this special case by just plotting a line. It assume this should be doable without too much coding, because just using the following code is already fast enough: "plot(x, y.*ones(size(x)))". This substitution code produces a line instead a series of circles, which is (a) much faster, (b) kind of Matlab compatible and (c) as helpful as the previous graphics output in my use case. But this might spoil the graphical output for users who actually do want this serious of cirles output. (What comes back to the question: Is the current Octave behavior documented for this case? Do we want to stay backwards compatible if not?)
• (D) We could speed up our Octave plotting code and still generate a row of circles. I am not sure how much work this would be, but I assume much more.