• 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: fast, threaded drawing to NSImageView from C ?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: fast, threaded drawing to NSImageView from C ?


  • Subject: Re: fast, threaded drawing to NSImageView from C ?
  • From: Bill Bumgarner <email@hidden>
  • Date: Tue, 30 Oct 2007 14:17:58 -0700

On Oct 30, 2007, at 1:10 PM, Rene Limberger wrote:
So for starters, does my code below remotely make sense? Is this the right approach? Our goal is to get the fastest tile update in our view as possible.

No. :)

In general, randomly spawning threads and pounding on the drawing infrastructure from said threads simply isn't going to work. Even if it did work, it isn't likely to be terribly fast as you are going to end up seriously contending for scarce resources like the connection to the window server, etc...

NSImage is an incredibly heavy weight class for just rendering to screen. Very likely not what you want. As well, the -lockFocus/- unlockFocus are contending for high level resources that shouldn't be arbitrarily diddled from threads.

In any case, I suggest taking a step back and *first* solving the problem of how to most quickly get bits to the screen. If you are just drawing a bunch of points and the sets of points are going to be interlaced, then using NSRectFillList() is the fastest way I found to get points to the screen without resorting to OpenGL.

See:

http://svn.red-bean.com/restedit/trunk/source/HopView.py

As an example. It is a simple HopView fractal which, with each iteration, has to draw a couple of thousand more pixels over an existing image. It accumulates the rendered image into NSBitmapImageRep instances, avoiding the overhead of NSImage. It isn't threaded, but the calculation portion could be trivially broken out into a thread (while the drawing code would remain relatively untouched). It happens to be implemented in Python, but it uses the stock Cocoa APIs -- there isn't anything in there that can't be directly translated to Cocoa (save for the generator used in the actual math bits).

Now, if your image is truly tiled -- if each set of points are isolated from each other -- then this may not be the fastest way to get the bits to the screen. Nor is it a particularly convenient way if your points are going to be varying in color.

Looking at your code, the easiest possible modification would be to move the NSImage out of the thread. Create NSBitmapImageReps in the thread, pass 'em to the main thread for rendering. And be very careful about memory management. That, at least, should move things to "working". Maybe the performance will be good enough (but I doubt it -- easier to optimize than debug threading issues, though).

b.bum

_______________________________________________

Cocoa-dev mailing list (email@hidden)

Please 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


References: 
 >fast, threaded drawing to NSImageView from C ? (From: Rene Limberger <email@hidden>)

  • Prev by Date: Checking to see if a server volume is already mounted?
  • Next by Date: Problem with NSImage in JNI
  • Previous by thread: fast, threaded drawing to NSImageView from C ?
  • Next by thread: Garbage collection, core data, and tight loops
  • Index(es):
    • Date
    • Thread