Re: optimizing compilers
Re: optimizing compilers
- Subject: Re: optimizing compilers
- From: Marcel Weiher <email@hidden>
- Date: Sun, 3 Feb 2002 10:30:02 +0100
On Saturday, February 2, 2002, at 07:55 , email@hidden wrote:
I think that the combination of Quartz and broken Cocoa display
semantics is
slow because my company sells a high end vector animation application
that
is much faster on a 266Mhz Pentium PC running Openstep than it is on a
450Mhz G4 running OS-X. I have posted many times on this subject.
Part of
the problem is that the Foundation classes got much slower between
Rhapsody
DR2 and OS-X. Part of the problem is that Quartz vector rendering is
slower
than Display Postscript used to be. We can work around the Foundation
framework problems, but we are stuck with slow (but admittedly more
capable)
Quartz.
I imagine you have benchmarks that support these assertions; but more
to the point, your application is a very special case.
I do. I modified Yap to use my own PS interpreter, and to time
interpretation and display separately. For just about every Postscript
file, the pure 'display' time on OS X was significantly higher than on
OS X Server 1.x (running on the same machine). On Server 1.x,
interpretation-time was usually the bottleneck, whereas on OS X display
time was.
That said, many simple things I benchmarked in isolation were actually
quite speedy, so I am not 100% sure what the problem is, though
line-drawing certainly springs to mind...
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 ;-)
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...
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.).
Were the bit depths, hardware acceleration, bus speeds, etc. such
that this was a fair comparison?
For me it was the exact machine, which dual-boots into OS X and X Server
1.2. It is a G3/233. As a matter of fact, I recall the G3/233 with X
Server yielding faster times than a Pismo/500 with X.
There are a huge number of factors that play into rendering that make
comparisons like this difficult.
Yes.
It may be the case that line rendering is slower on the 450Mhz G4
running OS X, while also being the case that Quartz is running just
about as fast as it possibly could within the parameters of that
environment.
It is often the parameters that need tuning.
Marcel