Re: Slowing scatter down for the sake of Matlab compatibility

[Ben Abbott]

On Dec 4, 2011, at 7:55 PM, Jordi Gutiérrez Hermoso wrote:

> 2011/12/4 Ben Abbott <address@hidden>:
>> On Dec 4, 2011, at 6:25 PM, Ben Abbott wrote:
>>> I tried the script below on ML R2011b.
>>> 
>>> for p = 0:5
>>> tic
>>> n = 10^p;
>>> x = rand (n,1);
>>> y = rand (n,1);
>>> colours = [ ones(n,1) zeros(n,1) zeros(n,1) ];
>>> colours(1,:) = [0 0 1];  % different color for first element
>>> hg = scatter (x, y, 15, colours);
>>> hp = findall (hg, 'type', 'patch');
>>> fprintf ('numel(x) = %d, numel(hg) = %d, numel(hp) = %d\n', numel (x), 
>>> numel (hg), numel (hp))
>>> fprintf ('Time to render = %f seconds\n', toc)
>>> end
> [snip]
>>> It appears that ML consistently creates one patch for each point.
>>> 
>>> Perhaps an option can be added to scatter() to skip ML
>>> compatibility? There is already a "filled" option. Can a "collect"
>>> option be added? Then the patches with consistent size, and color
>>> may be collected into a single patch?
> 
> Sigh... It's not much use if it's not the default behaviour...
> 
>> Using a modified test script
>> 
>> for p = 0:5
>> tic
>> n = 10^p;
>> x = rand (n,1);
>> y = rand (n,1);
>> hg = scatter (x, y, 15);
>> hp = findall (hg, 'type', 'patch');
>> fprintf ('numel(x) = %d, numel(hg) = %d, numel(hp) = %d\n', numel (x), numel 
>> (hg), numel (hp))
>> fprintf ('Time to render = %f seconds\n', toc)
>> end
>> 
>> numel(x) = 1, numel(hg) = 1, numel(hp) = 1
>> Time to render = 0.007314 seconds
>> numel(x) = 10, numel(hg) = 1, numel(hp) = 10
>> Time to render = 0.009084 seconds
>> numel(x) = 100, numel(hg) = 1, numel(hp) = 100
>> Time to render = 0.034167 seconds
>> numel(x) = 1000, numel(hg) = 1, numel(hp) = 1
>> Time to render = 0.017748 seconds
>> numel(x) = 10000, numel(hg) = 1, numel(hp) = 1
>> Time to render = 0.099743 seconds
>> numel(x) = 100000, numel(hg) = 1, numel(hp) = 1
>> Time to render = 0.964281 seconds
> 
> Okay, so is this the behaviour we must mimic? Create one patch object
> per dot unless there is no colour parameter passed and there are more
> than 100 dots?
> 
> Is there any way to speed this up? What's the big slowdown about
> calling __go_patch__ object thousands of times? Does this produce a
> redraw of the graphics every time? Is there a way to first record all
> the objects and only draw at the end?
> 
> - Jordi G. H.

No. As far as I know, calling __go_patch__ does not force a redraw.

Unless there is an explicit call to drawnow() nothing will render until the end.

However, since the above ML behavior isn't documented I no longer have a 
problem modifying Octave's behavior. The only reason I see is to avoid 
complaints by those who are used to ML's undocumented features.

Ben



Ben