Re: Speed of Quartz (was: optimizing compilers)
Re: Speed of Quartz (was: optimizing compilers)
- Subject: Re: Speed of Quartz (was: optimizing compilers)
- From: Marcel Weiher <email@hidden>
- Date: Tue, 5 Feb 2002 02:01:27 +0100
On Tuesday, February 5, 2002, at 12:34 , John C. Randolph wrote:
"Drawing 1000 individual moveto/lineto segments is essentially
equivalent to drawing 1000 independent thin rectangles of
various lengths at various orientations. Drawing a 1000 segment
connected/stroked path with round linejoins involves parallel
curve formation (including arc line joins), flattening the
curves,
This is all pretty harmless.
feeding the entire beast to the scan converter as a
huge self-intersecting polygon, resolving the self-intersections
to get the antialiasing right, etc...."
There we go. Figuring out (self-)intersections is inherently n^2,
although with some cleverness you may be able to shave a bit off in
common cases. Of course, the reason you have to get the
self-intersections is the anti-aliasing -- without it, you just draw
over yourself: no problem!
This is exactly the type of problem I was alluding to earlier: where
Quartz is slow despite probably doing close to the best possible for the
given problem, simply by making the original problem significantly
harder.
The fact that your path may not actually be self-intersecting at all
probably doesn't help either, because the system has to first figure
this out.
So, when you have a bunch of lines to draw, keep in mind that
intersections and line joins add up. BTW, it would appear that
round line caps/joints are somewhat more expensive than mitered
or square caps.
Probably insignificant if you have the self-intersection checking
problem.
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.