Re: CGDisplayCapture question
Re: CGDisplayCapture question
- Subject: Re: CGDisplayCapture question
- From: Mike Paquette <email@hidden>
- Date: Thu, 15 Jul 2004 08:23:18 -0700
On Jul 15, 2004, at 5:21 AM, Jim O'Connor wrote:
I don't need to use capture (which is how I tried it at first), but
SwitchToMode will be asynchronous without a capture (on the other hand,
evidence suggests that it isn't synchronous WITH it either). So if I
leave
out the capture, what is the recommended way to be sure the switch
happens
before I do further work?
The API:
CGDisplaySwitchToMode(CGDirectDisplayID display, CFDictionaryRef
mode);
Should be synchronous in 10.1.5 and later. The fade in effect run
after the display mode change is asynchronous.
The mode change operation has some unusual inter-application timing
effects, as programs which may be directly accessing the display
hardware need to be synchronously notified before the display mode
change can be performed. If a program is in a state where it is not
responding to events, it can delay the mode change several seconds. In
Mac OS X versions older than 10.3 this can have the effect of forcing
the display mode change to become asynchronous.
The display mode change notifications are delivered as part of the
event stream to each application. CGDisplaySwitchToMode() runs the
equivalent of a modal run loop while the mode change is in progress,
returning after either the mode change is complete or a timeout is hit
indicating a problem may exist. Your application can listen for the
mode change notifications and advance a state machine to ensure the
correct state exists before proceeding using the API introduced in
10.3:
CGError
CGDisplayRegisterReconfigurationCallback(CGDisplayReconfigurationCallBac
k proc, void *userInfo);
This registers a callback handler which receives the display state
change notifications for each display:
typedef void(*CGDisplayReconfigurationCallBack)(CGDirectDisplayID
display,
CGDisplayChangeSummaryFlags flags,
void *userInfo);
The equivalent Display Manager callbacks can be used in releases prior
to 10.3. See documentation for DMRegisterExtendedNotifyProc().
Display capture does interact with display mode changes, when all
active displays are captured.
When your program captures a display, the display hardware is removed
from the window system for purposes of state change notifications and
drawing operations. If your application captures all displays, then
when it makes a display mode change, there is no effect on things like
desktop layout, and your state change notifications are not sent to
other applications.
However, when your application releases the displays, while the display
is in a mode of operation other than that set from the user's
preferences, then the system has to notify all other apps that the
display is in a new state, so the desktop, app windows, and related UI
elements will appear correctly. The sequence of capturing the
displays, changing the display mode, and releasing the displays
produces a disconcerting amount of UI activity and flashing, and is not
something that I can recommend doing.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.