 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Mac Forum / Programming / Mac Programming / October 2004direct screen drawing?
I am trying to access the bitmap/pixmap of the port of a window. I've done this thousands of times with offscreen graphics worlds, which I then copybit to a window, but in my present application I would just assume write directly to the pixmap for a window. The program has no need for an offscreen gworld. However, the program viciously crashes and freezes my entire computer, can't be force quit, and forces me to reboot the machine. So far, all I've done is try to get the pixmap. I haven't made any attempt to write or alter anything in it yet. I am astounded that merely accessing the pixmap should be so lethal. For example: SetPort(GetWindowPort(mainWindow)); CGrafPtr port = GetWindowPort(mainWindow); PixMapHandle pixmapHandle = GetPortPixMap(port); PixMapPtr pixmapPtr = *pixmapHandle; Ptr baseAddr = pixmapPtr->baseAddr; short rowBytes = pixmapPtr->rowBytes; Rect bounds = pixmapPtr->bounds; short pixelType = pixmapPtr->pixelType; short pixelSize = pixmapPtr->pixelSize; Can anyone tell me why this is killing my entire system? And more usefully, how do I properly get at the pixmap for direct pixel writing? Apparantly the above approach is bad news. Thanks much. ________________________________________________________________________ Keith Wiley kwiley@cs.unm.edu http://www.unm.edu/~keithw "Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy." -- Edwin A. Abbott, Flatland ________________________________________________________________________ > I am trying to access the bitmap/pixmap of the port of a window. I've > done this thousands of times with offscreen graphics worlds, which I then [quoted text clipped - 5 lines] > attempt to write or alter anything in it yet. I am astounded that merely > accessing the pixmap should be so lethal. For example: Does mainWindow in fact exist at this point? > SetPort(GetWindowPort(mainWindow)); > CGrafPtr port = GetWindowPort(mainWindow); > PixMapHandle pixmapHandle = GetPortPixMap(port); > PixMapPtr pixmapPtr = *pixmapHandle; > Ptr baseAddr = pixmapPtr->baseAddr; Should be: Ptr baseAddr = GetPixBaseAddr(pixmapHandle); > short rowBytes = pixmapPtr->rowBytes; Should be: short rowBytes = GetPixRowBytes(pixmapHandle); on recent system. On older systems, you have to mask off the high order bits, which signify that this is a color pixmap. > Rect bounds = pixmapPtr->bounds; > short pixelType = pixmapPtr->pixelType; > short pixelSize = pixmapPtr->pixelSize; > > Can anyone tell me why this is killing my entire system? Probably the SYSTEM is still alive, but the window manager is dead. If you were doing a simulataneous remote login, you'd be able to tell. > And more > usefully, how do I properly get at the pixmap for direct pixel writing? > Apparantly the above approach is bad news. What makes you think this is every going to work in general? Remember that Macs have supported a multiple monitors on multiple video cards comprising a unified desktop for more than 10 years. If a window crosses multiple video cards, you can hardly expect direct access to the baseAddr of its pixmap to do anything useful. Further, on OS X, all windows are buffered anyway, and only by telling the O.S. what regions to draw to the actual screen with QDFlushPortBuffer() will anything ever actually get drawn. (The O.S. does it for you whenever your program calls WaitNextEvent(), or the equivalent when dispatching on a Carbon Event.) Just a quick question - I notice in your suggestions that you do without the global qd.thePort (a GrafPtr). Is it because it's been abandonned in OSX? Or is it only available in a few older compilers? I did notice in some very old mac programming books that they tell you to use thePort directly, as if it was some common ground global (which isn't in THINK C 6 or 7, for example. It's qd.thePort). > Just a quick question - I notice in your suggestions that you do > without the global qd.thePort (a GrafPtr). Is it because it's been > abandonned in OSX? Or is it only available in a few older compilers? > I did notice in some very old mac programming books that they tell you > to use thePort directly, as if it was some common ground global (which > isn't in THINK C 6 or 7, for example. It's qd.thePort). Yes, yes, yes. thePort used to be a standalone global. Then Apple introduced the "qd" structure (at the latest in System 6, which was when I started programming and I remember hearing about the old thePort but I never used it). When Carbon arrived, Apple introduced a whole bunch of APIs for getting the values that used to be in qd, which you're now supposed to be using. However, messing with thePort itself was actually "not recommended" already in System 7, where you were strongly encouraged to use GetPort() instead. Cheers, -- Uli http://www.zathras.de > Just a quick question - I notice in your suggestions that you do > without the global qd.thePort (a GrafPtr). Is it because it's been > abandonned in OSX? Or is it only available in a few older compilers? > I did notice in some very old mac programming books that they tell you > to use thePort directly, as if it was some common ground global (which > isn't in THINK C 6 or 7, for example. It's qd.thePort). In Classic Mac OS, you could safely cast a DialogPtr to a WindowPtr, and a WindowPtr to a GrafPort. Under Carbon on OS X, this no longer works, you MUST use the correct accessor functions to get from one data type to the other. > Further, on OS X, all windows are buffered anyway, and only by telling > the O.S. what regions to draw to the actual screen with > QDFlushPortBuffer() will anything ever actually get drawn. (The O.S. > does it for you whenever your program calls WaitNextEvent(), or the > equivalent when dispatching on a Carbon Event.) Yeah, I just avoided the issue and drew into an offscreen world and them blitting to the screen. It avoids the whole question. Thanks for the info anyway. It was helpful. Perhaps I'll try the direct way again at some point. ________________________________________________________________________ Keith Wiley kwiley@cs.unm.edu http://www.unm.edu/~keithw "Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy." -- Edwin A. Abbott, Flatland ________________________________________________________________________ > SetPort(GetWindowPort(mainWindow)); > CGrafPtr port = GetWindowPort(mainWindow); [quoted text clipped - 9 lines] > usefully, how do I properly get at the pixmap for direct pixel writing? > Apparantly the above approach is bad news. Learn to use a debugger. Step through the above code and see which of the various pointers end up being NIL. Lacking any additional info, I'd assume you are on a pre-OS X system and the window in question isn't a color port but rather a black and white one, so the pixmap is NIL/bad. > Learn to use a debugger. Step through the above code and see which of > the various pointers end up being NIL. I'm very good with a debugger, thank you very much, but they are hard to use, when stepping over a particular line crashes and freezes the entire computer, forcing a reboot. > Lacking any additional info, I'd assume you are on a pre-OS X system and > the window in question isn't a color port but rather a black and white > one, so the pixmap is NIL/bad. No, OS X, 32 bit color window. I just went ahead and did the old offscreen gworld with copybits approach. It's working fine now. ________________________________________________________________________ Keith Wiley kwiley@cs.unm.edu http://www.unm.edu/~keithw "Yet mark his perfect self-contentment, and hence learn his lesson, that to be self-contented is to be vile and ignorant, and that to aspire is better than to be blindly and impotently happy." -- Edwin A. Abbott, Flatland ________________________________________________________________________ |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.