Re: Quartz/memory benchmarks...
Re: Quartz/memory benchmarks...
- Subject: Re: Quartz/memory benchmarks...
- From: Charles Jolley <email@hidden>
- Date: Thu, 27 Jun 2002 00:24:55 -0500
Hi:
This e-mail is a little long. I just wanted to relay some of the
lessons I have learned working with Quartz for those who seem to be
interested in this sort of thing. Feel free to ignore!
A few observations I have made about Quartz while working on my projects:
1. It appears that one of the biggest bottlenecks is the actual drawing
command (even if it is just filling an area). I assume this is because
it is using some kind of PDF-based rendering engine to do the work,
which is not easily optimized. Of course, using a 3d system would seem
to be a great way to speed this up.
2. The image composite and dissolve operations seemed to get much faster
in 10.1. I suspect those have been optimized, hopefully to use graphics
accelerators. It could also be that they were accelerated for the G4.
I suspect a little bit of both since I saw some improvement on G3's and
vast improvements on G4.
My experience has been to try to minimize the amount of drawing I even
attempt in drawRects. Even though the clipping boundary should
theoretically keep extraneous drawing from taking up too much time, it
is often important to squeeze out as much performance as possible. When
drawing would be too complex, I had to find ways to hack NSView's so I
could capture a bitmap image of the view and just composite that graphic.
Case in point: My software, Okito Composer, displays palettes in a
tooldrawer to the side of the window. These palettes can be very
complex, each containing many different controls and subviews. Once I
added four or five of the palettes scrolling became unbearably slow,
even when I minimized my drawing to just the newly exposed space. To
make matters worse, I wanted to allow users to grab palettes and reorder
them, with all the other palettes sliding around to make room for the
palette the user was moving, much like toolbar items do in an
NSToolbar. Trying this, even with fairly well optimized code, was
slower than molasses on a 400Mhz G4.
After some experimentation I discovered that displaying an NSImage was
apparently well optimized in 10.1, so I set about trying to find a way
to draw these complex subviews into an offscreen image and then to
substitute the offscreen image for actual drawing during key times.
This turned out to be an incredibly difficult process because Cocoa
provides no easy way to obtain an image of a view and its subviews if
that view is not entirely on screen. I even used a technical support
incident for this, though even Apple DTS was not able to give me a very
good solution. (Although they did try, I'm not trying to criticize
them.)
Well, I finally got something that seems to work "well enough," but I am
not satisfied by it at all. Cocoa drawing would be much easier to
optimize if there was just some way to have a view produce an NSImage of
itself and its subviews.
The lesson I have drawn from this is that Quartz has fallen into the
classical trap of trying to provide a easy-to-use high-level environment
at the expense of ignoring the real-world needs of its users, namely the
ability to optimize how their application does its display. It sounds
like Apple is trying to address some of this with Quartz Extreme, but,
quite frankly, if they really care about making the Mac platform faster
they would do well to make all their information about optimizing under
quartz more public and not try to charge us so much for the privilege.
If Apple is serious about fighting their "Mhz-myth" problem, it would
seem to me that helping us application developers create faster
applications, would be a good step in that direction.
-C
On Wednesday, June 26, 2002, at 08:24 PM, Allan Odgaard wrote:
Okay, I did some more in-depth benchmarking.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.