Re: Data-dependent slowdown of NSBezierPath
Re: Data-dependent slowdown of NSBezierPath
- Subject: Re: Data-dependent slowdown of NSBezierPath
- From: Warren Nagourney <email@hidden>
- Date: Mon, 20 May 2002 14:22:36 -0700
For what it is worth, following John's suggestion, I used
[NSBezierPath strokeLinefromPoint:toPoint] and got a considerable speedup
with noisy data with no appreciable loss of image quality. I consider my
problem to be fixed.
Thanks to all who responded.
Warren Nagourney
--On Monday, May 20, 2002 3:27 PM -0500 "Erik M. Buck"
<email@hidden> wrote:
----- Original Message -----
From: "John C. Randolph" <email@hidden>
> 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...
Oh, for crying out loud! Yes, the Bezier path rendering is slow
when you have *thousands* of intersections. This is because
correct rendering of a path with self-intersections using a
translucent (or pattern) color requires that you figure out
where all the intersections are before you rasterize them.
DPS didn't anti-alias, and it only dealt with alpha when
compositing. I would also point out that DPS had a hard limit
on the number of segments a path could have, which Quartz 2-d
doesn't.
I agree with John C. Randolph completely. I even emphasized that Quartz
is doing a lot of work that other vector drawing APIs don't have to do
(in the previous post). The problem is that Quartz has no feature to
maximize performance of vector drawing without antialiasing and
transparent strokes. (It is possible to use a solid color and turn off
antialiasing, but things do not speed up enough) Therefore it is
practically impossible to get acceptable performance from Quartz in the
situation when maximum vector drawing speed is needed. The bottom line
is that the venerable old Display Postscript is faster for vector drawing
but admittedly may produce inferior quality output.
- Quartz is very slow when compositing images compared to software GL, and
don't even think about hardware GL.
- Quartz does not correctly composite scaled images that include
transparent pixels.
- Quartz/ATSUI text rendering is very powerful and very slow compared to
DPS Type I/III font rendering. (Quartz/ATSUI also provide features not
available with DPS Type I/III fonts)
- Adobe Acrobat is much faster at rendering arbitrary PDF than Preview. I
can only guess why :(
Quartz is wonderful technology that provides features unavailable from any
other vector drawing API that I am aware of. I applaud the creators of
Quartz. Unfortunately, Quartz is so slow that it is useless for many
applications. Fortunately, hardware accelerated OpenGL is available when
performance is important so we can all be happy :) Use Quartz when
quality is more important than speed. Use OpenGL when speed is more
important than quality. There is no such thing as a free lunch!
--------------------------------------------------------------------------
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.