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
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
--
Brian D. Ripley, [EMAIL PROTECTED]
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
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
----
Jochen Laubrock, Dept. of Psychology, University of Potsdam, Germany
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
_______________________________________________
R-SIG-Mac mailing list
[email protected]
https://stat.ethz.ch/mailman/listinfo/r-sig-mac
