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 14:23:48 -0800
NO. We were talking about wether Quartz is slow and wether Quartz's
speed (or rather lack thereof) could account for some of the perceived
sluggishness of OS X.
Actually, no. When this began (when I said "I assume you have turned
off antialiasing..." a few messages ago now), we were talking about a
specific line-drawing benchmark you had done that you claimed showed bad
performance from Quartz. Now it sounds like that benchmark wasn't fair
because you didn't turn off antialiasing around the line drawing, and it
also sounds like your code may be exercising a very specific bug in
either Quartz or NSBezierPath. None of this is at all relevant to
whether Quartz is responsible for general OS X sluggishness.
It is also relevant when you look at separate but connected choices.
Quartz has very good anti-aliasing of text, but that does seem to be
quite expensive. However, turning it off is not really an option
because the mechanisms for getting good quality text are not up to
snuff. The decision not to bother implementing advanced hinting and
automagic bitmap-substitution to quite the same extent as in DPS is
also understandable considering that the anti-aliasing is in-place and
meant as the default mechanism.
So, if you want to get reasonable text out of Quartz, you pretty much
have to use the anti-aliasing. From the *user* (of the APIs and the
computer) perspective, the comparison is therefore quite fair. Quartz
has to do more work, but Apple doesn't really give us a choice of not
doing this work.
This is what I meant when I said the code may not be bad, but still
slow. Choices have been made and we have to live with them.
Do you have any evidence that antialiased text is actually so slow? I
am fairly certain that antialiased bitmaps get cached for fonts,
somewhere in Quartz or the underlying layers, so I would be surprised if
it was really that much slower than non-antialiased text. In any case,
font rendering is not actually Quartz's problem, as I understand it, so
I *think* you're not actually complaining about the speed of Quartz
anyway, but of ATSUI or some other component.
I'd be interested in any benchmarks regarding speed of text drawing on
X that anybody has.
And you can do stroke adjustment for your lines yourself if you're
attached to it; that's a separate issue from antialiasing.
No you can't. Not realistically, at least. Stroke adjustment has to
be done in device space, meaning you cannot take advantage of
coordinate transformations provided by the imaging model, but instead
have to transform everything yourself. Apart from breaking modularity
quite seriously (think NSView hierarchy -> yes, I can get the CTM and
compensate based on that, but really...), it is also simply impossible
for included PDF files, at least with the tools provided by Apple. You
would then have to write your own PDF interpreter to decompose that etc.
I don't think so.
The fact that you can't do stroke adjustment for PDF files seems
fairly irrelevant -- the issue of stroke adjustment came up in the
context of your benchmark app that drew many many lines every second in
a continuously updating display. And in that context, doing your own
stroke adjustment, *if* you find it necessary to because you're turning
off antialiasing and you find the results you're getting to be
unaesthetic, seems perfectly reasonable. It's not hard, and it doesn't
really break any "modularity" in any serious way. Either that, or you
could live with what you get without stroke adjustment -- I personally
find it hard to believe that the user is going to notice the difference
in a continuously updating display, which is the test case where this
whole issue came up in the first place. In a less intensive setting
where continuous updating was not happening (such as PDF), I think
antialiasing probably isn't going to produce a significant slowdown, so
the issue there is moot. So there is no problem.
Yes I can, because the choices Apple has made essentially don't give me
another realistic option. Apart from that, path-rendering does seem to
have issues all of its own. Maybe there's some QDGX code lurking there?
I still don't even see the problem. You can turn antialiasing on or
off. You can do your own stroke adjustment or not. You've got more
power than you ever had with DPS (not to mention QD). If your benchmark
app is written properly its performance is fine, as testified to by
someone who has actually done this themselves. There does appear to be
a performance problem with paths containing many segments, but that's a
pretty special case, can be worked around easily for most applications
(including the one you described), and will probably be fixed soon in
any case. And the remainder of Quartz is nice and fast.
Quartz is the best-designed, highest-quality and fastest rendering
system I've ever had the pleasure of using, and I've been doing Mac
programming since 1984. I am amazed on a daily basis by what it is
capable of doing and how fast it does it. Perhaps we should give Apple
credit for a job well done, instead of complaining about nits. And
perhaps, unless someone has a good benchmark to the contrary, we
shouldn't assume that it is responsible for the poor performance of OS X.
And with that, I'm done with this thread. My apologies to anyone for
whom this has already dragged on too long.
Ben Haller
Stick Software