On 26/10/2009, at 11:21 AM, Quincey Morris wrote:
On Oct 25, 2009, at 17:00, Graham Cox wrote:
I've found that caching to a PDF doesn't gain much performance wise
- a little, but not that significant. Since a PDF essentially
records whatever paths you create and rasterizes them, that's no
surprise
Could well be, though it depends on whether PDF creation or
rendering has any path optimizations built in.
I'm still guessing, but I think the big win in terms of performance
-- before going to something like image caching -- is going to be:
a. Use NSBezierPath immutably. (Mutating NSBezierPath objects seems
a *much* less common case, so I suspect the immutable cases are
likely better optimized in the frameworks.)
b. Coalesce paths with the same drawing characteristics into a
single NSBezierPath object, and keep such objects around
(regenerating them only when edits are made). Unfortunately, the
desired drawing order makes this a bit more complicated and less
effective, but if we're talking about representing stitches made
with a continuous length of thread, then it's likely that drawing
order and drawing characteristics are fairly tightly linked. Also,
it's really triple NSBezierPath objects, not single ones, because
the whole point is to draw each thread with 3 paths, and that has
drawing-order implications as well.
Profiling in DrawKit shows that the real killer is rasterizing paths
(CGContextStrokePath, etc). Complex bezier paths naturally take longer
than simple ones, but recreating, mutating or even chopping up a
bezier path into a different path (shorter, or with special effects
applied such as a taper) is invariably not the major factor.
If you need to stroke a path three times to get a given effect, then
the stroking will be where it's spending time, even if the path is
being copied or recreated three times. Of course, there's no reason to
do that - just stroke the same path three times, it will be slightly
more efficient, but the emphasis is on "slightly".
If you cache to a PDF, depending on what you do, that can actually be
slower. One reason is that if you keep your own drawing list and
carefully cull objects not needing to be drawn against the view's
current dirty rect list, you can do minimal drawing. Caching to a PDF
loses you the opportunity to do this (if you cache to one big PDF that
is) because the whole PDF will need to be iterated and drawn, and even
if much of that drawing is clipped out it still takes more time to
determine clipping than culling against dirty rects, I found. I ended
up disabling PDF caching on this basis because it was consistently
slower. I guess if you cached individual graphic objects to separate
PDFs you might get a win because you can cull AND get any speedups
from the PDF drawing.
Bitmap caching is the big winner, but as I.S. mentioned, if you are
zooming in and out a lot, you'll have to recache a lot to avoid
pixellation (at least on a zoom in - zoom out you'll probably get away
with drawing a bitmap with scaling), and that may end up being
practically slower.
What's needed is for the Core Graphics guys to magically come up with
an order of magnitude speed gain when stroking and filling paths -
that would be a huge win for everyone! ;-)
--Graham
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
