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

>> 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>

[demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s]
_______________________________________________
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>)



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.