Re: Can I get AppKit to draw this faster ?

FROM : Nat!
DATE : Tue Oct 08 23:41:22 2002

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_removed>
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.