Re: Data-dependent slowdown of NSBezierPath
Re: Data-dependent slowdown of NSBezierPath
- Subject: Re: Data-dependent slowdown of NSBezierPath
- From: "Erik M. Buck" <email@hidden>
- Date: Mon, 20 May 2002 01:07:28 -0500
- Organization: EMB & Assocites Inc.
Quartz is so slow at rendering crossed paths that it is useless for that
purpose. Either avoid crossed paths or don't use Quartz. You can always
use OpenGL.
Line joins may also slow down Quartz vector drawing, but not as much as
crossed paths.
My advice is to use OpenGL for drawing whenever possible because in spite of
what Mike Paquette says, Quartz is ridiculously dog slow for almost all
operations including image compositing, font rendering, vector paths, and
fills. It is actually fairly fast at clipping to arbitrary paths, but
obviously not as fast as OpenGL with a hardware stencil buffer.
For reference, Display Postscript on Openstep on a 1.8 GHz Pentium IV is 4
to 10 times faster than Quartz on a 450 MHz G4 when benchmarked with a very
real commercial vector drawing application. Your mileage may vary, but the
application used does nothing special or particularly taxing. It does have
some crossed paths (but no crossed fills). Quartz has many nice features,
but in some ways it is a major downgrade from Display Postscript.
P.S. Mike Paquette is a very nice brilliant guy. I would hire him in a
minute! He is just wrong about the speed of Quartz. No one likes to have
their baby called slow, and parents will defend their children to the death
in the face of overwhelming evidence, Quartz is Mike's baby, so...
----- Original Message -----
From: "Warren Nagourney" <email@hidden>
To: <email@hidden>
Sent: Monday, May 20, 2002 12:17 AM
Subject: Data-dependent slowdown of NSBezierPath
>
I have noticed a strange thing when using NSBezierPath: there is a
dramatic
>
drawing slowdown when I display "noisy" data.
>
>
My application is a simulation of a Fourier Transform Spectrometer which
>
generates simulated data that depends upon several parameters and then
>
takes the Fourier transform (to retrieve the original spectrum). It is
>
extremely fast: with 1000 points of data, I can smoothly change the
various
>
parameters (using sliders) and see the transform smoothly change in the
>
expected manner.
>
>
However, when I add some noise to simulate a more realistic situation, the
>
program slows down enormously. The noise generator (a random number
>
generator) is always in place, so it is not the culprit - also, turning
off
>
the FFT doesn't help. It seems to be the display alone which is slowing
>
things down.
>
>
Can someone suggest changing some parameter to speed the drawing up when
>
displaying noisy data? I have tried changing the "Flatness" and turning
off
>
antialiasing (using the setGraphicsContext) to no avail (in fact turning
>
off antialiasing made the graphics look terrible AND slowed it down as
>
well).
>
>
Thanks.
>
>
Warren Nagourney
>
>
--------------------------------------------------------------------------
>
Warren Nagourney <email@hidden> Voice: 206-543-9585
>
University of Washington 206-543-0143
>
Physics Dept., Box 351560, Seattle, WA 98195 Fax: 206-685-0635
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.