Re: Cocoa graphics speed
Re: Cocoa graphics speed
- Subject: Re: Cocoa graphics speed
- From: Shaun Wexler <email@hidden>
- Date: Mon, 29 Sep 2003 18:53:12 -0700
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.