Fullscreen/Window using same context

Apprentice
Posts: 17
Joined: 2005.05
Post: #1
Hi,

I'm trying to get my program to be able to toggle between fullscreen and windowed mode since it currently only supports fullscreen. Most places that I've looked say that you must use two contexts, one specifying AGL_FULLSCREEN, the other not, and then using aglCreateContext's share parameter to "share" textures, etc between the two...

I was reading Apple's "Context Sharing Tips" page and noticed that right at the bottom they say this:

Quote:To further simplify the sharing of windowed and full screen pixel formats the ability to use full screen pixel formats with windowed drawables has been added to Mac OS X v10.3 Panther. This means a client can create one pixel format with full screen specified and use it to support both windowed and full screen contexts. The requirements for a full screen pixel format to explicitly support a single display and for shared pixel formats to support the exact same screen configuration have not been relaxed and must still be satisfied.

So I tried that, keeping AGL_FULLSCREEN in my pixel format and just using aglSetDrawable to change the context to draw to the window... Doesn't work. No errors, I just get a blank window. If I remove AGL_FULLSCREEN from the pixel format it works fine. I'm running MacOS X 10.3.7 with a Radeon Mobility 9200.

I'd be nice if this worked...

Thanks,
Adam
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #2
I've always just created two separate contexts. It's not too difficult to do.

If you want some example code, you might want to take a look at OpenGLWindow.c in the Water Tower 3D source code: http://www.sacredsoftware.net/software/w...rce.tar.gz

- Alex Diener
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #3
You need two contexts. You can share a fullscreen context with a windowed context like the technote says, but you can't attach a fullscreen context to a windowed drawable.

Alternatively, you could not use a fullscreen context. Instead use a window the size of the screen and set its level to CGShieldingWindowLevel. That will let you use only one context, and you can even animate the zoom between window and fullscreen if you want. However, the performance in "fullscreen" mode will definitely be worse than a real fullscreen context, because windowed contexts have to copy on swap instead of using HW pageflipping. So, I don't recommend this approach (unless you need to do something silly like run the software renderer "fullscreen"...)
Quote this message in a reply
Apprentice
Posts: 17
Joined: 2005.05
Post: #4
arekkusu Wrote:You need two contexts. You can share a fullscreen context with a windowed context like the technote says, but you can't attach a fullscreen context to a windowed drawable.

But, isnt that what the technote says you dont have to do? Ok, so I should create two contexts, but if I follow the technote I could use the same pixelformat right? I don't quite get it. Because, when I was testing it before, if I use a pixelformat that has AGL_FULLSCREEN specified it does not work on a window... But the technote says it will...

Quote:This means a client can create one pixel format with full screen specified and use it to support both windowed and full screen contexts.

So is the technote wrong?

Confused,
Adam
Quote this message in a reply
Member
Posts: 156
Joined: 2002.11
Post: #5
I create one window with one context and then capture and release the display as necessary, and just promote the window group level. It's a lot easier.

BTW, CGShieldingWindowLevel won't do it, at least in my case. You gotta use kCGMaximumWindowLevel in Carbon.

I believe I saw a technote saying that rendering to a window is actually faster than to the fullscreen port.

There some source code here: http://webpages.charter.net/utopiaplanet...Struct.dmg, where you can find an example. The code has evolved a bit though in the past few months. Let me know if you are interesting in following this path and I give you the newest version.
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #6
Matrix Wrote:But, isnt that what the technote says you dont have to do?
No, the technote is worded a little confusingly in the last paragraph. It is talking about 10.3's support for sharing _objects_ between fullscreen and windowed contexts. It does not say that you can attach a fullscreen context to a windowed drawable. That fails with "invalid drawable" when you try.

FCCovett Wrote:I believe I saw a technote saying that rendering to a window is actually faster than to the fullscreen port.
Oh? Where was that? I was just comparing, it definitely is slower for me. In a simple "clear the screen, draw a cube" test:
windowed shieldinglevel ctx: ~1200 fps
fullscreen ctx: ~1700 fps

Of course that's an artificial test, it mostly just swaps buffers. A real app will spend most of its time actually drawing stuff so the difference is much less.
Quote this message in a reply
Member
Posts: 116
Joined: 2002.04
Post: #7
Quote:However, the performance in "fullscreen" mode will definitely be worse than a real fullscreen context, because windowed contexts have to copy on swap instead of using HW pageflipping. So, I don't recommend this approach (unless you need to do something silly like run the software renderer "fullscreen"...)

Is that really true? I thought that using CGL or AGL fullscreen mode just gave a slight performance benefit because the Window Server could basically stop processing while the display is captured.

I have a need to be able to display the system input window for complex characters. The only way I can see to do this in fullscreen is to use a full-screen sized window. (It definitely does not work if the display is captured, as one would expect) But, it's going to stink if the performance is that poor.

I guess I could do as FCCovett says - create one window, capture the display and uncapture it if the user has a complex input-method selected. Any thoughts on this appreciated.

Wade
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #8
It's the difference between a VRAM->VRAM copy (back buffer to the window) vs a HW pageflip (toggle "base address" register.)

With the speed of today's VRAM (many GB/sec) I wouldn't say the windowed swap performance is "poor"... but it is doing more work than a real fullscreen context. Hopefully that little bit isn't enough to drop you from i.e. 60fps to 58 fps... but that depends entirely on what else your app is doing.
Quote this message in a reply
Member
Posts: 156
Joined: 2002.11
Post: #9
This is what I found, and it pretty much confirms what Arekkusu says:

"Page flipping:
[...]
Note that the benefits of page flipping have become less and less pronounced as hardware and software technology has advanced. The typical gain is only a few frames per second since VRAM to VRAM blitting is so fast on modern hardware."
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #10
Mm hmm. Kent Miller's analysis is here though it is a bit dated now...
Quote this message in a reply
Apprentice
Posts: 17
Joined: 2005.05
Post: #11
But I don't get an error... Its kinda weird... And i dont think that last paragraph is talking about objects in a context...

To further simplify the sharing of windowed and full screen pixel formats the ability to use full screen pixel formats with windowed drawables has been added to Mac OS X v10.3 Panther.

To me that reads... you can now, as of MacOS 10.3 use a FULLSCREEN PIXEL FORMAT with a WINDOW DRAWABLE.

I tried that and it does not work...
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #12
You are confusing pixel formats and OpenGL contexts. What that technote says (badly worded) is that you can use the same pixel format to create two different contexts, one for full-screen and another for windowed mode. They ought to replace "drawable" with context.

So, you can specify 1 pixel format with AGL_FULLSCREEN, and use it to create 2 contexts, one for full screen, and the other for windowed mode. You also still need 2 drawables.
Quote this message in a reply
Apprentice
Posts: 17
Joined: 2005.05
Post: #13
Yes, but if i then create a context using a pixel format that has AGL_FULLSCREEN and then attach it to a window it doesn't work...
Quote this message in a reply
Sage
Posts: 1,232
Joined: 2002.10
Post: #14
This is my interpretation of the last paragraph (bold parts changed):

"To further simplify the sharing of windowed and full screen contexts the ability to share full screen contexts with windowed contexts has been added to Mac OS X v10.3 Panther. This means a client can create one pixel format with full screen specified and use it to share with both windowed and full screen contexts. The requirements for a full screen pixel format to explicitly support a single display and for shared contexts' pixel formats to support the exact same screen configuration have not been relaxed and must still be satisfied."

The original wording about "sharing pixel formats" is confusing-- you share contexts, not pixel formats! The rest of the document is written correctly, I guess the last paragraph was tacked on after 10.3 shipped.
Quote this message in a reply
Hunter
Unregistered
 
Post: #15
Er? What did I do to get myself banned? Did I insult somebody?

I know I shouldn't have reregistered but still...
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  SDL. How to hide fullscreen window e40pud 1 4,068 Mar 11, 2010 01:23 PM
Last Post: cmiller
  Full screen context doesn't remain the current context Malarkey 3 3,518 Feb 1, 2007 05:27 PM
Last Post: OneSadCookie
  Copying from OpenGL window to other window Ingemar 7 4,867 Nov 4, 2006 03:50 AM
Last Post: OneSadCookie
  Fullscreen/Window Setup/toggle skyhawk 10 4,884 Oct 13, 2006 04:05 PM
Last Post: skyhawk
  Strange FullScreen Context Issue kodex 10 5,237 Aug 26, 2005 02:50 AM
Last Post: OneSadCookie