• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Data-dependent slowdown of NSBezierPath
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Data-dependent slowdown of NSBezierPath


  • Subject: Re: Data-dependent slowdown of NSBezierPath
  • From: "John C. Randolph" <email@hidden>
  • Date: Mon, 20 May 2002 12:16:28 -0700

On Sunday, May 19, 2002, at 11:07 PM, Erik M. Buck wrote:

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

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.

-jcr


John C. Randolph <email@hidden> (408) 974-8819
Sr. Cocoa Software Engineer,
Apple Worldwide Developer Relations
http://developer.apple.com/cocoa/index.html
_______________________________________________
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.

  • Follow-Ups:
    • Re: Data-dependent slowdown of NSBezierPath
      • From: "Erik M. Buck" <email@hidden>
    • Re: Data-dependent slowdown of NSBezierPath
      • From: Lance Bland <email@hidden>
References: 
 >Re: Data-dependent slowdown of NSBezierPath (From: "Erik M. Buck" <email@hidden>)

  • Prev by Date: Re: Tear off...
  • Next by Date: Re: [ANN] Developer for rent
  • Previous by thread: Re: Data-dependent slowdown of NSBezierPath
  • Next by thread: Re: Data-dependent slowdown of NSBezierPath
  • Index(es):
    • Date
    • Thread