Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa graphics speed

On Sep 29, 2003, at 4:45 PM, Nat! wrote:

I just coded something fairly similiar (though only with 16384 rectangles). The speed was frustrating. AFAIK you can't do much about it in Cocoa. You can do a little better if you have the possibility to cache the color, and only set them if it changes. I was only drawing black and white blocks and caching the color and avoiding the -set, got me somewhere like a 30% speedup. But a 30% faster snail is still no sprinter...

In the end I used a lot of little views (64) instead of one big view and I "hand draw" everything into one NSBitmapImageRep or one view and blit those during -drawRect. I went from 0.5 fps to "quite sufficient" (>15 fps) with that approach :) It doesn't look quite as pretty though.

One big problem of Cocoa (and maybe even Quartz) with drawing lots of little stuff is that there is too much locking going on. Everytime you call NSRectFill there is a internally lock opened and closed :), which kills your performance. A big improvement would be to expose the locks (probably in graphics context) and feature some non-locking calls, but that's something only Apple can do.

In the previous version of my app, I use CG directly to handle all performant drawing. There are frequency response curves which are redrawn every frame, over a static background. I cache the background in a CGImage, and blit that each time into another CGImage, which is passed to the bezier curve drawing code. Then the completed image can be flushed to the window. This way, all locking is done on the CGImage, not on the CGContext of the window's bitmap, which is where the latency lies. Locking on the CGImage is an order of magnitude more efficient for all drawing. I can get 640x480 frame rates of 60 fps on a 500 MHz G4, and well above screen refresh capabilities at nearly any size with a dual 1.42-GHz G4. Of course, the new version is going to use OpenGL, for higher performance, but mainly to alleviate the huge CPU hit incurred with CG, which for my app is about 70% of its total CPU time, including all the complex DSP/FFT and I/O.
--
Shaun Wexler
MacFOH
http://www.macfoh.com
_______________________________________________
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.
References: 
 >Re: Cocoa graphics speed (From: Nat! <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.