[R-SIG-Mac] quartz device extremely slow (2.7.0)
Tomas Mikoviny
tomas.mikoviny at gmail.com
Mon Apr 28 17:57:24 CEST 2008
I use MacBook (late 2006), Leopard 10.5.2
Model Name: MacBook
Model Identifier: MacBook2,1
Processor Name: Intel Core 2 Duo
Processor Speed: 2 GHz
Number Of Processors: 1
Total Number Of Cores: 2
L2 Cache: 4 MB
Memory: 2 GB
Bus Speed: 667 MHz
Boot ROM Version: MB21.00A5.B07
SMC Version: 1.13f3
On 28 Apr 2008, at 16:41, Byron Ellis wrote:
> It would be interesting to know which machine Thomas is using. If it
> were, say, an iBook it wouldn't be that surprising to learn that
> Quartz Extreme was not working as well as one might hope and falling
> back on a software renderer.
>
> On Mon, Apr 28, 2008 at 9:12 AM, Simon Urbanek
> <simon.urbanek at r-project.org> wrote:
>> 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
>>>
>>>
>>>
>>
>> _______________________________________________
>> R-SIG-Mac mailing list
>> R-SIG-Mac at stat.math.ethz.ch
>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>
>
>
>
> --
> Byron Ellis (byron.ellis at gmail.com)
> "Oook" -- The Librarian
>
> _______________________________________________
> 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