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: Mon, 4 Feb 2002 20:53:36 +0100
On Monday, February 4, 2002, at 07:18 , email@hidden wrote:
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. :->
No, it might mean that specific choices have been made that don't allow
for a fast implementation. These were then followed
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?
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.
So none of this font-hinting bitmap-caching stuff is relevant, no?
It is very relevant, especially as you yourself noted that the "complex
paths" problem is probably not encountered very often. Text is. It is
all over the place!
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.
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.
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.
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?
Marcel
--
Marcel Weiher Metaobject Software Technologies
email@hidden www.metaobject.com
Metaprogramming for the Graphic Arts. HOM, IDEAs, MetaAd etc.