[R-SIG-Mac] quartz device extremely slow (2.7.0)
Byron Ellis
byron.ellis at gmail.com
Mon Apr 28 18:41:52 CEST 2008
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
More information about the R-SIG-Mac
mailing list