[R-SIG-Mac] quartz device extremely slow (2.7.0)

[Jochen Laubrock]

Just a wild guess (not using 2.7.0): maybe there is some memory  
allocation going on Quartz-internally, and the block size has changed  
between Tiger and Leopard?

The following sample code from apple might be related, it shows and  
measures performance of 4 different ways of drawing lines: (1) as  
separate CGPaths, (2) as a single CGPath, (3) using the new bulk line  
drawing function in Tiger, and (4) by limiting the number of lines  
drawn: http://beta.devworld.apple.com/samplecode/QuartzLines/ 
QuartzLines.zip

In a nutshell,
(1) for() { CGContextBeginPath(); CGContextMoveToPoint();  
CGContextAddLineToPoint(); CGContextStrokePath(); }
(2) CGPathCreateMutable(); CGPathMoveToPoint(); for ()  
{ CGPathAddLineToPoint(); }
(3) /* construct point array in memory, then */  
CGContextStrokeLineSegments();
(4) as (3), but use fewer points. not quite as accurate due to  
undersampling

On my system, benchmark results are
(1) 28.1 ms (10000 lines, 356k lines/sec)
(2) 4.9 ms  (10000 lines, 2053k lines/sec)
(3) 4.0 ms  (10000 lines, 2484k lines/sec)
(4) 1.6 ms  (898 lines, 561k lines/sec)

The current approach used in RQuartz_Polylines, (1), seems to be  
slower than what can be achieved by, e.g., using (2) or (3).


On Apr 27, 2008, at 16:36, Tomas Mikoviny wrote:

> OK I've checked the RQuartz_Polyline and RQuartz_Polygon. Its quite
> straight forward. However I don't see anything causing problem we
> discuss.
>
> tomas
>
>
> # Revision 45515: /branches/R-2-7-branch/src/library/grDevices/src
> -----------
>
> static void RQuartz_Polyline(int n, double *x, double *y, CTXDESC)
> {
>      if (n < 2) return;
>      int i;
>      DRAWSPEC;
>      if (!ctx) NOCTX;
>      SET(RQUARTZ_STROKE | RQUARTZ_LINE);
>      CGContextBeginPath(ctx);
>      CGContextMoveToPoint(ctx, x[0], y[0]);
>      for(i = 1 ; i < n; i++)
> 	CGContextAddLineToPoint(ctx, x[i], y[i]);
>      CGContextStrokePath(ctx);
> }
>
> static void RQuartz_Polygon(int n, double *x, double *y, CTXDESC)
> {
>      if (n < 2) return;
>      int i;
>      DRAWSPEC;
>      if (!ctx) NOCTX;
>      SET(RQUARTZ_FILL | RQUARTZ_STROKE | RQUARTZ_LINE);
>      CGContextBeginPath(ctx);
>      CGContextMoveToPoint(ctx, x[0], y[0]);
>      for(i = 1; i < n; i++)
> 	CGContextAddLineToPoint(ctx, x[i], y[i]);
>      CGContextClosePath(ctx);
>      CGContextDrawPath(ctx, kCGPathFillStroke);
> }
> ------------
>
>
>
> On 27 Apr 2008, at 15:08, Prof Brian Ripley wrote:
>
>> Some versions of Windows GDI have a superficially identical problem
>> -- stroking a path is quadratic in the number of segments.  The  
>> solution we used (in gdrawpolyline, in src/extra/graphapp/gdraw.c)
>> was to split the drawing into pieces of length 1000, and that could
>> be used here.  It would be a simple modification to RQuartz_Polyline
>> and RQuartz_Polygon, so please try it and let us know how you get on.
>>
>> It would also have been helpful to (C-level) profile the call and
>> find out where the time is being spent -- I expect it not to be in R
>> at all but in Quartz.
>>
>> On Sun, 27 Apr 2008, Tomas Mikoviny wrote:
>>
>>> I found where is the problem, however have no solution for it right
>>> now.
>>> To demonstrate (I have chosen 6000 to match my datasets size):
>>>
>>> x=seq(1:6000)
>>> y=rnorm(6000)
>>> plot(x,y)
>>>
>>> Absolutely no problem until now, everything is responsive, no lags.
>>>
>>> Problem appears when I insert parameter 'type':
>>>
>>> slowdown and unacceptable lag for "l", "o", "s"
>>> plot(x,y, type="l")
>>> plot(x,y, type="o")
>>> ...
>>>
>>> however no problem at all  (instantly plotted) for "p", "b", "c",  
>>> "h"
>>> plot(x,y, type="p")
>>> plot(x,y, type="b")
>>> ...
>>>
>>> Does anyone know possible reason for this behaviour. Once again, I
>>> use
>>> clear install of R version 2.7.0 (2008-04-22). When I try the same
>>> stuff with latest 2.6.2 version everything runs smoothly without any
>>> problems.
>>>
>>> tomas
>>>
>>>
>>> On 27 Apr 2008, at 10:49, Charles Hebert wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've the same problem + the resizing of the window is really really
>>>> slow... for all datasets. I'm running leopard 10.5.2 and the latest
>>>> macOS R dmg.
>>>>
>>>> For all datasets. But when i use quartz() then plot, it seems ok
>>>> (slow again but... usable). So right now, i use quartz(file,
>>>> type="pdf")...
>>>>
>>>> Best regards,
>>>>
>>>> Charles
>>>
>>> _______________________________________________
>>> R-SIG-Mac mailing list
>>> R-SIG-Mac at stat.math.ethz.ch
>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>
>>
>> -- 
>> Brian D. Ripley,                  ripley at stats.ox.ac.uk
>> Professor of Applied Statistics,  http://www.stats.ox.ac.uk/~ripley/
>> University of Oxford,             Tel:  +44 1865 272861 (self)
>> 1 South Parks Road,                     +44 1865 272866 (PA)
>> Oxford OX1 3TG, UK                Fax:  +44 1865 272595
>
>
> 	[[alternative HTML version deleted]]
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac

----
Jochen Laubrock, Dept. of Psychology, University of Potsdam, Germany