• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Can I get AppKit to draw this faster ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Can I get AppKit to draw this faster ?


  • Subject: Re: Can I get AppKit to draw this faster ?
  • From: Ali Ozer <email@hidden>
  • Date: Mon, 7 Oct 2002 19:28:40 -0700

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.

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).

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...

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.

Ali
_______________________________________________
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.

  • Follow-Ups:
    • Re: Can I get AppKit to draw this faster ?
      • From: Nat! <email@hidden>
References: 
 >Can I get AppKit to draw this faster ? (From: Nat! <email@hidden>)

  • Prev by Date: Embarrassing NSURL problem
  • Next by Date: Tearing down a DO connection
  • Previous by thread: Can I get AppKit to draw this faster ?
  • Next by thread: Re: Can I get AppKit to draw this faster ?
  • Index(es):
    • Date
    • Thread