Re: Full screen and popup menu
Re: Full screen and popup menu
- Subject: Re: Full screen and popup menu
- From: Brian Christensen <email@hidden>
- Date: Thu, 23 Sep 2004 20:28:41 -0400
On Sep 23, 2004, at 19:36, Ricky Sharp wrote:
In particular, a full-screen GL context may place the hardware in
states that cannot be supported by the window system. That's why the
documentation on using full-screen GL contexts recommends capturing
the display, removing the display from the window system.
It's not clear to me what exactly this comment applies to. From what I
am reading problems may or may not occur when using a full-screen GL
context. The sparse documentation on CGDisplayCapture() makes no
mention of any potential problems:
"When an application captures a display, Quartz does not allow other
applications and system services to use the display or change its
configuration.
To prevent updates by direct-to-screen programs (such as Classic),
Quartz draws a shield window that fills the entire screen of a captured
display. Note that the graphics context associated with a shield window
is not a full-featured drawing context."
The only potential issue that I see here is that I can't assume that
the shielding window has a full-featured drawing context, but I'm not
trying to draw to the shielding window anyway. If I never instantiate a
GL context and never "place the hardware in states that cannot be
supported by the window system," is there any reason I should assume
that there would be a problem? I understand that simply setting the
window level is good enough for many cases, but it only goes so far.
What if I need a particular display resolution? There is no kosher way
to keep window and icon arrangements from getting screwed up during a
resolution switch without doing a display capture and keeping it
captured for the duration of the app. Personally, other than the pop-up
menus not appearing I have encountered zero problems using
CGDisplayCapture() together with Cocoa windows, buttons, controls, etc.
Nor I have yet to see a single user send in a report that the
application isn't working on their hardware.
Given no other usable solution (short of drawing my own controls or
using OpenGL) I'm not sure what we are supposed to be doing
differently.
/brian
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden