Re: Quartz/memory benchmarks...
Re: Quartz/memory benchmarks...
- Subject: Re: Quartz/memory benchmarks...
- From: Paul Fox <email@hidden>
- Date: Thu, 27 Jun 2002 10:22:42 +0100
>
Date: Thu, 27 Jun 2002 00:24:55 -0500
>
Subject: Re: Quartz/memory benchmarks...
>
Cc: email@hidden
>
To: Allan Odgaard <email@hidden>
>
From: Charles Jolley <email@hidden>
>
>
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.
Here here! Someone else agrees with what I see - slow as molasses in
liquid nitrogen.
I am busy building a benchmarking simple demo app to show why
my app runs like a snail on heat.
My initial results show that string drawing is a killer - about 4mS
per call. That may seem fast to some people, but take a multi row
multi column table view and that translates easily into a 50 or more
calls for a not particular big screen). Thats 50*.004 = 0.2 second
just to draw the strings. (Line drawing is much fast as would be expected).
Now hit the up or down arrow a number of times and we are into real slow
response.
This is using [NSString drawAt:]. I have experimented with directly
calling the NSLayoutManager and as yet I am 25% slower than NSString, so
I am missing some optimisations.
I'm going to see if I can go lower - Quart2D or the CG funcs to see if
I can get anywhere nearer an order of magnitude improvement.
Its so funny - when/if people eventually buy this app I can say:
Well you can run the native Cocoa version - sure, or you
can use the included X11 version which requires XFree86 but it
will run 10x faster.
I think Apple should carry on with Cocoa and provide a complete new
API with none of the anti-aliasing, floating-point co-ords crap and
give us something as fast as X. Heck even have the X server fire up
at run time, and provide Carbon/Cocoa/X11 APIs for people to choose from.
If I worked at Apple, I would be ashamed.
And for every Apple worker, there are 100s of us developers going thru
the same crap - figuring out why our apps are slow.
I thought Java was slow, but Java is a godsend compared to Cocoa and Quartz.
I really hope QuartzExtreme/Jaguar is faster, else ...
+-------------------------------------------------------------------------+
| CRiSP - Flexible editor | CRiSP, syn. for BRIEF |#
| | Internet: email@hidden |#
| If you get no reply for | WWW: (mine)
http://www.crisp.demon.co.uk |#
| support, please check your | WWW:
http://www.crisp.com |#
| Reply-To: email address. | WWW:
http://www.pacemaker.co.uk |#
+-------------------------------------------------------------------------+#
###########################################################################
_______________________________________________
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.