Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
 
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CopyBits and dual monitor configration

Copying an Offscreen Image Into a Window

http://developer.apple.com/documentation/QuickTime/INMAC/MACWIN/imOffGraphWorlds.7.htm

"As long as you're drawing into an offscreen graphics world or
copying the image out of it, you must leave its pixel image locked."

Michael
Orbital Launch & Lift, Inc.
The MacOS X setuid Helper Tool Experts
http://www.orbitallaunch.com

At 7:47 PM -0500 7/29/04, Scott Thompson wrote:
>>> Strictly speaking calling LockPortBits should not be necessary.
>>> QuickDraw should lock the destination port's bits before accessing the
>>> destination port's bits.
>>
>>I don't think that's true. Any call that modifies the port's bits
>>directly should always be bracketed by lock/unlock calls:
>>
>>"If you're writing code that reads or modifies the port bits
>>directly, you should bracket your code with calls to this function
>>and UnlockPortBits."
>
>That's true if you are going to modify the port bits yourself, that
>is to say you are going to use GetPixBaseAddr and use the row bytes
>to manually bit-swizzle the pixels. In that case you have to call
>LockPortBits (particularly on a window's port where LockPortBits has
>to make sure the back buffer is set up and UnlockPortBits lets the
>system know that you are done messing with the pixels so it can copy
>the bits forward)
>
>In this case the poster was going to modify the bits through
>CopyBits. That is NOT is not modifying the port bits directly.
>
>>The page mentioned above says that this is true "if you use
>>Quickdraw or Quartz 2D to draw", but it's pretty clear that they
>>mean only basic QuickDraw calls like "PaintRect, FillRect", etc.
>
>That's not at all clear. In fact the exact opposite is implied by
>the page you are quoting. Through that page it is made clear that
>if you use any QuickDraw calls INCLUDING CopyBits that the buffer
>locks will be handled for you. It says quite clearly that you have
>to handle the LockPortBits call only if you need direct access to
>the pixels through the base address.
>
>This is reinforced by the knowledge that it is the LockPortBits call
>which will cause your window's back buffer to loose it's
>acceleration on Mac OS X as discussed in the recent QD deprecation
>discussion. Any time you call LockPortBits on a window in Tiger
>you will indicate to the system that that window's back buffer
>cannot be kept in VRAM and will disable hardware acceleration for
>that window. CopyBits is certainly one of the calls that can take
>you through that path.
>
>>It's clear from the page above that CopyBits needs the LockPortBits
>>call before drawing. Since CopyBits can cause memory to be moved,
>>you have to be sure that the pixels are locked down in both the
>>source and destination before you call CopyBits.
>
>CopyBits is not very likely to cause cause memory to be moved on Mac OS X.
>
>According to John Iarocci in the Low-Level Carbon toolbox team in
>his Carbon performance discussions at WWDC the past couple of years,
>most handles on Mac OS X will not move once they are allocated
>unless you specifically make a call to do something like reallocate
>the handle to a larger size or call something like MoveHHi.
>
>What's more the HLock routine on Mac OS X is largely a no-op with
>the exception that it has to change the locked flag of the handle so
>that that flag will be correct if you call HGetState. The point of
>his mentioning that was that, calling HLock in a tight loop on Mac
>OS X can actually degrade performance unnecessarily.
>
>>From experience it sounds to me more like you have a SetPort
>>problem. Believe it or not in some instances a call to CopyBits
>>must be preceded by a call to SetPort in order to make the window
>>you want to draw into the current drawing port (the destination
>>pixmap is the pixmap of a window, that is). This concept is
>>somewhat analogous to setting the 'context' when drawing in OpenGL.
>
>On this we agree. I would check to see that the port you are using
>as the destination of the CopyBits call is actually the port of the
>window you are copying the bits into.
>
>It is not the case that you have to have the current port be the
>destination port, but it is a good idea nonetheless. It is also a
>good idea to make sure the Foreground color is set to black and the
>background color is set to white before making a CopyBits call as
>well.
>
>--
>Macintosh Software Engineering Consulting Services
>Visit my resume at <http://homepage.mac.com/easco/RSTResume.html>
>
>
>Attachment converted: 10.3:smime.p7s ( / ) (000ACBD2)
_______________________________________________
carbon-development mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/carbon-development
Do not post admin requests to the list. They will be ignored.

References: 
 >CopyBits and dual monitor configration (From: "Dotzler, Josef" <email@hidden>)
 >Re: CopyBits and dual monitor configration (From: Ken Worley <email@hidden>)
 >Re: CopyBits and dual monitor configration (From: Scott Thompson <email@hidden>)
 >Re: CopyBits and dual monitor configration (From: OL&L Lists <email@hidden>)
 >Re: CopyBits and dual monitor configration (From: Scott Thompson <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2007 Apple Inc. All rights reserved.