quartz device extremely slow (2.7.0)
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