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

At 4:05 PM -0500 7/29/04, Scott Thompson wrote:
> >> I have a strange problem when using CopyBits in a dual monitor
>>> configuration.
>>> When calling CopyBits to draw into a window, the bitmap is sometimes
>>> drawn on
>>> the main screen relative to the top left corner of the main display
>>> instead of
>>> relative to the desired graphics port. Calling PaintRect to erase the
>>> destination rect immediately before calling CopyBits is always OK,
>>> only the
>>> bitmap is sometimes drawn in the wrong place.
>>> However, this problem does not occur when nothing is drawn on the
>>> second
>>> screen. But as soon as I move some of my windows onto the second
>>> screen,
>>> CopyBits becomes unreliable.
>>
>> Are you calling:
>>
> > ::LockPortBits(::GetWindowPort(theWindowRef));
>>
>> on the destination window before the CopyBits? That's the first thing
>> that springs to my mind.
>
>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:

http://developer.apple.com/documentation/Carbon/Reference/QuickDraw_Ref/qdref_main/function_group_3.html#//apple_ref/c/func/LockPortBits

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

>Now... I'm not trying to say that it does, and it certainly doesn't
>hurt to make doubly sure, but the QuickDraw routines in general are
>savvy about locking the destination GWorld before manipulating their
>pixels.

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

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.

I would also ask what exactly is the source that you are trying to
draw into the window *from* with CopyBits? Is it a PixMap? Or is it
the field of some other QuickDraw data structure which happens to be
a PixMap also?

You may want to check out Goo Library and some of it's Carbon
window/drawing routines which may make your job a little easier:

http://www.michael-amorose.com/software/goolibrary/index.htm

In particular GWorldToWindow , GetWindowPortBitMapForCopyBits,
LockWindowPortBits, and UnlockWindowPortBits may be of help to you.

Hope this helps,

Michael
_______________________________________________
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: 
 >Re: CopyBits and dual monitor configration (From: Ken Worley <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.