Why doesn't Create take a Display?

OpenGL Development
#21

So the only difference between fullscreen and windowed mode in terms of BaseGL.nCreate is the presence of a border on the window? E.g. decorated/undecorated?

Windows are always created on the the “current” display in whatever ‘mode’ the display happens to be in? If you you haven’t set the DisplayMode before creating your window, then it is expected to be created on/over the desktop window?

I’ll leave it to Greg to figure out how that fits the Mac way of doing things… He told me earlier that windowed mode would not be supported on the Mac. If I recall correctly he felt that it just didn’t fit with how LWJGL was doing things. Maybe it can fit after all, I don’t know.

P.S. Thanks for being patient…

#22

No, I thank you for being patient.

[quote]So the only difference between fullscreen and windowed mode in terms of BaseGL.nCreate is the presence of a border on the window? E.g. decorated/undecorated?

Windows are always created on the the “current” display in whatever ‘mode’ the display happens to be in? If you you haven’t set the DisplayMode before creating your window, then it is expected to be created on/over the desktop window?
[/quote]
Absolutely correct, with a few minor details. E.g. in windowed mode, the window is expected to cooperate with the OS. That is, being able to be moved (but not resized), correct focus, etc. Moreso, detecting that the window is minimized or being closed by the user would be nice to implement (isMinimized and isClosed).

  • elias
#23

That section of code isn’t likely to change as Windowing mode won’t be supported under CGL and I’m not going to rewrite it to work with AGL (which is what it would require). So on OSX the refresh rate will be locked to 60Hz.

It can fit, its just not high on my list of things to do.

#24

Enlighten me - what’s the difference between CGL and AGL? I’d guess AGL is the mac equivalent of WGL and GLX, and that CGL is some kind of “smarter” interface. But what exactly is better, and why doesn’t CGL support anything else than fullscreen?

  • elias
#25

You can get all the gory details here: http://developer.apple.com/techpubs/macosx/Carbon/graphics/OpenGL/opengl.html

CGL stands for Core OpenGL

AGL, The Apple GL library contains the implementation of OpenGL functions and commands specific to the Mac OS windowing system. http://developer.apple.com/techpubs/macosx/Carbon/graphics/OpenGL/AGL_OpenGL/index.html

Looking through the docs it I see that AGL is the way to go to attach an OpenGL context to a window, CGL is good enough for fullscreen. AGL is primarily implement trhough CGL it seems… but I didn’t see any documentation for how you would create a GL context for a window with straight CGL… I think it is fairly complicated, as AGL supports dragging a window such that it lies across two different displays that could have different graphics controllers. That’s something that I wouldn’t want to emulate with only CGL, and I don’t know if you can force a window on to only one display… so that is probably why you are forced to deal with AGL to let it map things to the windowing system.

Since the current Mac port is all based on CGL it would take some time to switch to AGL. I might be able to assist in that transition once everything is working with CGL… but at this stage I’m not sure how much changing to AGL will affect the current architecture.

#26

“AGL also transparently manages renderers across multiple monitors. For example, a user can drag a window from one monitor to another despite the fact that their display capabilities may be entirely different and that they may be driven by dissimilar graphics cards with dissimilar resolutions and color depths.”

from http://developer.apple.com/techpubs/macosx/Carbon/graphics/OpenGL/AGL_OpenGL/index.html

There’s also the “green triangle” example that seems to create a windowed OpenGL app through something called Cocoa, what is that all about?

The example starts at
http://developer.apple.com/techpubs/macosx/Carbon/graphics/OpenGL/OpenGL/chap4/index.html

  • elias
#27

Cocoa is the name of the object oriented APIs written in Objective-C… from what I hear the Cocoa framework is quite cool, but I haven’t forced myself to get used to Objective-C, so I can’t say much about them.

The Java 1.4.1 JRE on Mac uses Cocoa, the 1.3.1 used ‘Carbon’, changing over from one APi to the other was part of what took so long to get 1.4.1 out on the Mac… but the even model in Cocoa worked much better with the Java event model etc… and as I understand it Cocoa is the way to go to get the best OS support.

Carbon is a straight C API, not object oriented… think of Win32. Cocoa is like MFC that doesn’t suck.

One of these days I will know enough Mac stuff to determine the level of difficulty in moving from CGL to AGL in LWJGL… but maybe if we are lucky, Sun will have official OpenGL bindings and Apple will port them by then.

#28

[quote]Cocoa is the name of the object oriented APIs written in Objective-C… from what I hear the Cocoa framework is quite cool, but I haven’t forced myself to get used to Objective-C, so I can’t say much about them.
[/quote]
Cocoa is a higher level API for writing applications for OSX. Its Objective-C based and while its easier to build graphical GUI applications, it is completely foreign for any developer on any platform other than native OSX developers. Since others are going to be taking the leading OSX role shortly, I didn’t want to force people to learn Objective-C in order to keep the OSX port up to speed.

That’s not correct. In order to better handle Swing and native OS graphics bindings it was desired to move over to Cocoa.

Carbon is a straight C API like Win32. Cocoa is like writing applications for OSX in another language altogether. One must learn a new language and syntax to do Objective-C.

The level of difficulty is moderate. You’ll have to rewrite the input code and the graphics code (including using QuickDraw or something else to switch resolutions in fullscreen).