quartz device extremely slow (2.7.0)

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

--
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]]

----
Jochen Laubrock, Dept. of Psychology, University of Potsdam, Germany

-- 
Byron Ellis (byron.ellis at gmail.com)
"Oook" -- The Librarian