Re: Can I get AppKit to draw this faster ?
Re: Can I get AppKit to draw this faster ?
- Subject: Re: Can I get AppKit to draw this faster ?
- From: Nat! <email@hidden>
- Date: Tue, 8 Oct 2002 23:41:22 +0200
Am Dienstag, 08.10.02 um 04:28 Uhr schrieb Ali Ozer:
For a little animation I am calling NSImage's
[self drawInRect:dstRect
fromRect:srcRect
operation:NSCompositeSourceOver
fraction:1.0];
repeatedly over the same image, dstRect and srcRect have always a
width of 1.0 and srcRect has also a fixed height (the image height),
but dstRect has varying heights, but always smaller than srcRect's
height.
When I do this with a 60x60 image (drawing 60 lines), I can keep up
with my 30 Hz animation, but if I use a 128x128 image (drawing 128
lines), my fps count drops to 15 Hz, which means I max out at around
2000 of these calls per second on my 400 Mhz cube - which I think is
pretty sad.
Any hints ? The only solution I can come up with is to write my own
"drawRect." method that blits into a NSBitmapImageRep.
Are you just drawing the NSImage in a loop, or are you using the
NSView display machinery for each step through the loop? If latter,
declaring your view to be opaque (override isOpaque: to return YES)
will help. (Seems like part of your sample is in the parent views,
that is why I ask.) Calling allocateGState on your view might also
help.
I am drawing the NSImage in a loop. Or in other words my NSView's
drawRect: routine is called up to 30 times a second, and that routine
then calls 128 times NSImages -drawInRect:fromRect: to actually draw
the effect.
NSImage's drawInRect:... is general purpose, and will scale your image
as needed. In cases where no scaling is needed, it should be much
faster. You might be able to see this if you use the same sizes for
the dst and src rects. In addition, using just the compositeToPoint:
method might give you further performance, especially if the image is
cached (you can do this with lockFocus/unlockFocus on 10.1, or with
the explicit setCacheMode: method in 10.2).
A good tip, but unfortunately my intended effect very much depends on
scaling.
If compositing ends up being considerably faster, actually caching the
NSImage at various interesting sizes and compositing is another
solution. However, it does reduce flexibility of course...
Interestingly in my case I experience the opposite. If I turn off
caching and I get an improvement in speed. Not substantial enough yet,
but better. Here are some measurements (ran these a few times so they
are stable)
// NSImageCacheNever = 5.2s
// NSImageCacheBySize = 5.35s
// NSImageCacheAlways = 5.7s
(I am running with 16,7 Mio Colors. The image is 24 bit)
BTW, I am no graphics wiz, but if your image was 32 bits, and assuming
on the average you're drawing half size, seems like you're drawing at
a rate of 128 x 64 x 4 x 2000 -> 60 megabytes / second... I don't know
how close or far this is from the possible best rate for a 400MHz > cube.
60MB/s would be sweet indeed, alas it's only 2000 lines/s -> 2000 * 128
* 4 = 1MB/s. Just a ballpark figure of course.
Looking some more at the Sampler.app output it seems that the AppKit
and CoreGraphics is more busy locking internal resources, than actually
drawing. I suspect there is no way for me to escalate these locks,
outside of my drawing loop ?
Ciao
Nat!
Jedenfalls sind zehn Fehlstarts hintereinander [E. Fuchs]
ein sehr interessanter Beweis
fuer unsere Theorie
von der natuerlichen Ueberlegenheit des Dezimalsystems
_______________________________________________
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.