Getting to an NSWindow's pixels - Printable Version
+- iDevGames Forums (http://www.idevgames.com/forums)
+-- Forum: Development Zone (/forum-3.html)
+--- Forum: Graphics & Audio Programming (/forum-9.html)
+--- Thread: Getting to an NSWindow's pixels (/thread-3426.html)
Getting to an NSWindow's pixels - ThemsAllTook - Mar 12, 2007 11:05 AM
I'm kicking around a bunch of different approaches for blitting image data to a Cocoa window. My current implementation uses NSDrawBitmap, which works, but there are some situations where I'd be able to sidestep filling out a pixel array to pass to it (essentially doing an extra blit) if I could get a pointer to the window's back buffer and blit directly into it.
I hacked up a quick test that essentially did this (which worked surprisingly well):
That code will of course raise all kinds of "deprecated, unsafe, bad, etc." flags in people's heads (and the compiler), so here's my question: Is there some way to access this pointer without going through deprecated QuickDraw functions?
Also, does anyone know of a reason off the top of their head that this definitely will not work in 10.5 or some other situation in the present or near future? If it's a viable approach despite deprecation, I might be able to just go ahead and do it this way...
Getting to an NSWindow's pixels - OneSadCookie - Mar 12, 2007 11:41 AM
I believe QuickDraw does not exist for 64-bit 10.5, so if you think some users of your program might want it to use more than 4GB of RAM (not completely absurd for an image editor) then you'll want to avoid it.
It's also the case that where you have window scaling going on that the pixels in the back buffer won't map 1-1 with the pixels in your image. You can test that out using Quartz Debug on 10.4, I think, though I think there may also be some minor API changes related to it in 10.5. I suspect NSDrawBitmap will work as poorly as CopyBits in this case...
My thought would be to grab the CGContext for the window, check if it's a bitmap context (and if not fall back to a less efficient method), check if it's the number of pixels wide and high you expect (and if not fall back to a less efficient method), and then do the direct blit into the CGBitmapContext's pixel buffer, which can only be in a very few different formats.
Getting to an NSWindow's pixels - ThemsAllTook - Mar 12, 2007 11:52 AM
Ooh, you can get a CGContext for an NSWindow? Sounds great! I'll have a look when I get home...
Getting to an NSWindow's pixels - ThemsAllTook - Mar 12, 2007 04:54 PM
Didn't work out as well as I'd hoped. [[NSWindow graphicsContext] graphicsPort] gives me a CGContextRef, but not a CGBitmapContextRef. I can draw into it with Quartz 2D API calls and stuff, but I can't actually get at the pixels directly. Ah well, I guess NSDrawBitmap will do well enough...
Getting to an NSWindow's pixels - sammyjojo - Jun 5, 2007 08:05 PM
I'm trying to do something similar too, except that I don't really mind if I can't get direct access to a window's pixels, but I would like to be able to draw some sort of "offscreen" buffer to a window.
At first I thought I could use a CGImage and draw into and then draw that into a window's context, but there doesn't seem to be able a way to access the pixel of data of a CGImage because the data could be in a non-directly accessible format.
I know that the Apple's Quartz 2D guide says that people used to create a bitmap context and use that as "offscreen" buffer, but they use CGLayer now instead. I know that I can get direct pixel access of a bitmap context, but how do I then draw that context to another? Is that even possible?