• 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: Speed problems using NSImage. Solution?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Speed problems using NSImage. Solution?


  • Subject: Re: Speed problems using NSImage. Solution?
  • From: Erik Buck <email@hidden>
  • Date: Sun, 7 Jan 2007 16:04:35 -0500

I don't disagree with the advise I have seen so far. To summarize the advice:
1) Use one of the awesome profiling tools available to find out where the performance problems are, or
2) Use some other API like OpenGL or Core Image which is implemented with OpenGL.


In particular, any game should probably use OpenGL.

However, using NSImage to draw 4 to 8 800x600 images and a little boat icon should be plenty fast on any G5 system. NSImage is ultimately implemented on top of OpenGL too.

I notice that there are lots of little inefficiencies in the posted code, and I have a hard time believing that 800x600 tiles are really needed for either waves or water.

It is silly to rotate the boat image, draw it in another newly created image, and then draw the newly created image. Just draw the rotated boat image directly to the view, but that is not causing a huge slowdown.

Just profile you application and find out where the time is spent and where the bottle neck is!



Here's a back of the napkin estimate:

600x800 time 4 bytes per pixel is ~2Mb per image.
8 Images are ~16Mb total.

4 images use NSCompositeSourceOver and fraction:.4 which requires that every pixel is read as well as written in order to correctly implement the composite and adds another 4 times ~2Mb worth of data movement.
----------------
Approximate Total memory read and written per frame is 24Mb



18 frames per second times 24Mb per frame is 432Mb per second. 30 frames per second times 24Mb per frame is 720Mb per second.


Now, don't get me wrong: 432Mb per second is obviously doable because you are doing it.
720Mb per second needed for a 30Hz update should be doable too, but it doesn't leave much bandwidth for the computer to do anything else.


Depending on the type of computer you have, all of the data may have to cross a PCI bus which has a theoretical maximum throughput of 500 to 1000 Mb per second. (4 or 8 bytes at 133 MHz using DMA)

In Mac OS X, all windows are double buffered which may increase the amount of memory being copied in some cases.

Summary:
The technique being used is sloppy and incredibly wasteful, but should be feasible.
Using OpenGL and/or Core Image would at least move the large images to the graphics card and relieve the poor CPU from having to copy all that data (432 to 720 Mb/s).






_______________________________________________

Cocoa-dev mailing list (email@hidden)

Do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Speed problems using NSImage. Solution?
      • From: John Stiles <email@hidden>
  • Prev by Date: Re: Document-Based App Woes
  • Next by Date: Re: Figuring out if we have an active gateway
  • Previous by thread: Re: Speed problems using NSImage. Solution?
  • Next by thread: Re: Speed problems using NSImage. Solution?
  • Index(es):
    • Date
    • Thread