Re: fast scatter plots - advice sought

[Michael D Godfrey]

On 01/11/2010 11:57 AM, David Bateman wrote:

Jaroslav Hajek wrote:

On Mon, Jan 11, 2010 at 8:17 AM, David Bateman <address@hidden> wrote:
 

Jaroslav Hajek wrote:
   

hi,

I recently started some work where I'm going to use scatter plots
heavily with a few thousand points.
I found out, however, that scatter plots were unusably slow with so
many points. This has also been reported before:

http://old.nabble.com/scatter3-is-really-slow-to24312164.htm

by this changeset
http://hg.savannah.gnu.org/hgweb/octave/rev/2f435ed48143

I tried to optimize the plotting strategy to get more reasonable
times, especially in the simplest cases. The old strategy of creating
one object per point is only used for small numbers of points (<= 20).
Otherwise, the points are split into subsets with common color and
size, and these subsets are plotted using a single primitive. This
seems similar to what Matlab does.

     

If this is done in the baackend ok, but I deliberately didn't make this
change in the frontend as it breaks matlab compatibility

   

What breaks Matlab compatibility? Please explain. Note that it is
*not* true that Matlab always creates one object per point (as you
seemed to imply in the above linked mail), at least in 2007a. It does
so only when there is a small number of points:
 

I wrote scatter with individual patch objects because that was the way matlab worked when I tested it, though I mght have missed the 100 point transition to a single patch object... It should however keep using patch objects for compatibility and to allow the use of colormaps with scatter plots like

n=100; x=randn(1,100);y=randn(1,100);c=sqrt(x.^2+y.^2); scatter(x,y,2,c); colormap hot

I don't see how you can support that with line objects, and if it you did it wouldn't keep the same children hierarchy for compatibility

D.

"matlab compatibility" should not be carried too far here.  How many users would be
affected by changes in the children hierarchy?  Absolute matlab compatibility would require
the the handle values returned by Octave to match those in matlab.  I do know of one program which
depends on this!  But, I think too much has been made of the compatibility issue in this case already.
Matching functionality and achieving best performance should be the main point.  If I understand
the current proposed code, it does this very well (subject to testing and verification for both
gnuplot and fltk backends).

Michael