Re: Speed of Quartz (was: optimizing compilers)
Re: Speed of Quartz (was: optimizing compilers)
- Subject: Re: Speed of Quartz (was: optimizing compilers)
- From: email@hidden
- Date: Mon, 4 Feb 2002 10:18:03 -0800
The quoted snippets here are parts of several other messages; I'm just
trying to avoid wasting bandwidth here. Sorry if this is found strange
or annoying. :->
While I totally agree about all the points you make, it still can't
be the relevant factors, because then Carbon apps should feel
noticeably snappier than Cocoa app, which in fact they do not.
Yes, I was focussing on Cocoa since that's what I know. Presumably
Carbon has its own speed problems. But this is the cocoa-dev list. ;->
I stand by my assertion that for the typical user who perceives
slowness in most operations on OS X, Quartz is not a factor.
That is a brave assertion ;-)
Nevertheless. :->
And by default, Quartz does the extra work of antialiasing, which DPS
didn't do.
Yes. The question is not wether the code is bad, but wether it is
slow...
Oh. Well, if "slow" means "slower than one would *like* it to be",
and can be used even with regard to code that is as fast as it could
possibly be given what it does, then everything in the system is
slow. :->
I assume you have turned off antialiasing with [NSGraphicsContext
setShouldAntialias:] for a fair test?
Turning off anti-aliasing is not an option, because the result is
generally unusable. Quartz obviously lacks the mechanisms used in DPS
to deal with low-resolution rendering (font hinting, automatic
substitution of tuned bitmaps, stroke adjustment for lines etc.).
Um... we were talking about line-drawing, not text, right? So none of
this font-hinting bitmap-caching stuff is relevant, no? And you can do
stroke adjustment for your lines yourself if you're attached to it;
that's a separate issue from antialiasing. So turn off antialiasing,
draw your lines, and then turn it back on so other drawing still looks
nice. If you're comparing DPS's line-drawing speed with Quartz's, but
you don't turn off anti-aliasing, you can hardly call that a fair test.
The outcome is that things often get surprisingly slow, even when no
drawing at all is involved. The first time the user asks for my
browser's contextual menu it takes anything from 5 to 10 seconds (with
the rainbow cursor spinning) for the menu to appear - it seems to get
cached afterwards, but that seems excessive to me, and I have yet to
find out how to pre-load it without bogging down application
initialization.
Rainer, perhaps you can do some of the work involved in a background
thread just after startup?
But if I were you, I would first do a profile to find out what is
actually so slow about this. This sounds highly suspicious to me.
Absolutely. We have exactly the same problem with Quartz speed. One of
our
apps needs to draw a sound waveform, fast enough to allow it to scroll
in
real time while the sound is playing...
The performance of Quartz was atrocious...
Dietmar's analysis of this was interesting and useful, and it sounds
like there may indeed be a specific bug in Quartz that causes poor
performance when drawing paths with many segments (have you logged this
bug on Apple's Bug Reporter, Dietmar?). This still has no speed
implication for system performance in general, though, as this is a very
specific case. So I still stand by my assertion. ;->
I don't know enough about how Quartz works internally to know whether
arcs and/or beziers are flattened into many-segment paths prior to
rendering or not. If they are, this bug might have negative performance
implications for drawing of curved paths in general, too, depending upon
the value of the flatness attribute. Anybody know?
Ben Haller
Stick Software