[R-SIG-Mac] quartz device extremely slow (2.7.0)
Simon Urbanek
simon.urbanek at r-project.org
Mon Apr 28 18:12:05 CEST 2008
Jochen,
thanks for the analysis,
On Apr 28, 2008, at 5:11 AM, Jochen Laubrock wrote:
> 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),
That is not what RQuartz_Polylines uses. It uses calls from (1) but
loop from (2). Interestingly, this is one of the fastest way:
(1) 82.6kl/s
(RQuartz) 1469kl/s
(2) 1138kl/s
(3) 1556kl/s
[iMac G5, 100k lines test modified from the sources above]
As you can see, the way we draw lines is just slightly slower than (3)
which would require us to allocate extra space. Using a path is slower
than what we use. Hence I'm not convinced that it is the issue.
However, I agree that Thomas' example is surprising to say the least
(given the speeds above it should take fractions of a second). I'm
running some more tests to find out what causes it (the time is spent
in CoreGraphics, but the question is why as there is no reason).
This is a paradox situation, because the new R Quartz device uses
Quartz Extreme and GPU rendering, so especially things like drawing a
line should be very fast ...
I'll keep you posted.
Cheers,
Simon
> 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
>
> _______________________________________________
> R-SIG-Mac mailing list
> R-SIG-Mac at stat.math.ethz.ch
> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>
>
More information about the R-SIG-Mac
mailing list