• 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: Screen snapshot example code posted
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Screen snapshot example code posted


  • Subject: Re: Screen snapshot example code posted
  • From: Ben Haller <email@hidden>
  • Date: Sat, 13 Aug 2005 09:10:31 -0700

Yeah, I'm familiar with Josh's code, I emailed with him before settling on the code I posted (and I'm cc:ing him on this in case he's interested). Josh's code reads the pixel values directly from screen memory, and upon reflection I decided that was not an approach that I thought was good. (Which is ironic for those who remember that, way back in the day, I was a strong advocate of direct-to- screen graphics; but all we had back then was QuickDraw :->).

One reason is that it gets very complex when you want to capture just a small rect, but that small rect could cross monitor boundaries and so forth; Josh's code takes the easy way out by only capturing the entirety of a single monitor. Generalized code to work with an arbitrary rectangle gets more hairy, especially if you don't want to take the performance hit of just capturing monitors in full first and then cropping down.
On the flip side, it's probably slow compared to what the core video system could do itself; reading pixels one by one is not as fast as getting down-and-dirty with cacheline reads and such, and certainly isn't as fast as copying from one buffer on the video card to another without involving the CPU at all, which is what the system perhaps does (or should do, or someday will do) on at least some accelerated video cards. The way that Josh's code has to tweak each pixel on the way through is something the video card or the AltiVec chip or whatever ought to be able to accelerate, similarly, and the system graphics primitives probably already do that.
Finally, it's uncomfortably dependent upon the layout of video memory; Josh's code only works for 16-bit and 32-bit color, and only with interleaved (non-planar) data, which is fine for now AFAIK, but Apple has made no guarantees about sticking with only those memory layouts in the future that I am aware of. It's possible right now to switch the screen to 8-bit mode, and many games do, but Josh's code wouldn't be able to take a snapshot of the screen in that state, while my CopyBits-base code probably would (haven't tried). And so forth.


This is probably all a bit off-topic -- not a lot of Cocoa being discussed here -- but anyhow, that's why Ryan and I didn't go with Josh's solution.

Ben Haller
Stick Software


On Aug 13, 2005, at 7:02 AM, Andreas Mayer wrote:



Am 13.08.2005 um 06:48 Uhr schrieb Ben Haller:



Presumably there's a way to do this through CoreGraphics or CoreImage, but I don't know those APIs...



This seems to work for me:

http://cs.northwestern.edu/~josha/code.htm


Andreas



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Screen snapshot example code posted
      • From: Mike Paquette <email@hidden>
References: 
 >Screen snapshot example code posted (From: Ben Haller <email@hidden>)
 >Re: Screen snapshot example code posted (From: Andreas Mayer <email@hidden>)

  • Prev by Date: NSTableView, bindings, and a background color
  • Next by Date: Activating controls in a child window
  • Previous by thread: Re: Screen snapshot example code posted
  • Next by thread: Re: Screen snapshot example code posted
  • Index(es):
    • Date
    • Thread