JOGL API Feedback

OpenGL Development JOGL Development
#1

First order of business - the methodology for handling resolutions sucks. That’s really the best way I can describe it - sorry.

Two things that must absolutely make their way into GLCanvas or similar:

.setFullScreen( )
.setFullScreen( DisplayMode )

.enumerateAvailableDisplayModes()

  • should be tied to either DisplayMode instances that come back from the standard JDK1.4 fullscreen API (then we can check and see if those modes are hardware accelerated).

The, yet other, binding to GL that I have uses the Fullscreen Mode API and lets the application choose a display mode, set to that mode, and them passes that drawing surface to the native rendering code.

These are a MUST for doing fullscreen games (or something equivalent).

Talk to me Goose!

#2

For a long time I’ve been unsuccessfully trying to understand how full screen support works on e.g. Windows, where some drivers apparently enable triple buffering (faster than monitor refresh rates without disabling the sync to vertical blanking) for full-screen games. I’ve searched the net fairly extensively and tried to find the appropriate code in the Quake sources, but the SciTech MGL was so opaque I couldn’t figure out where it bottomed out into real Windows API calls.

The JDK’s built-in full screen support on Windows actually has two implementations, depending on whether -Dsun.java2d.noddraw=true is specified. Theoretically, it is a must to pass this command line flag to any Java application using OpenGL on Windows because of driver-level incompatibilities between DirectDraw and OpenGL, and the Java2D implementation uses DirectDraw for some operations by default.

The -Dsun.java2d.noddraw implementation of full-screen support uses the WinGDI API ChangeDisplaySettings and related calls, without getting DirectDraw involved. The existing component’s size is changed (to the best of my recollection) and it is positioned to take up the full screen.

A few months ago I looked at LWJGL’s full-screen support and saw that it seemed to pass several different flags to the window creation process than the AWT does. I’d like to do a prototype with JOGL that does similar operations and creates a window without using the AWT. The new APIs I’ve been thinking of would be along the lines of

GLDrawableFactory:
DisplayMode[] getDisplayModes();
GLDrawable createFullscreenDrawable(DisplayMode, GLCapabilities, GLCapabilitiesChooser);

The reason to avoid using the AWT’s GraphicsDevice class is that you can’t get enough platform-specific information from it (I’ve tried in the past, probably while working on GL4Java).

I don’t think GLDrawable would have to change though we might want to add a sub-interface called GLFullscreenDrawable or similar which would add some methods for switching back from full-screen mode without terminating the application. (GLPbuffer does the same thing without exposing a concrete class in the public API.)

Let me know what you think about this.

#3

Actually this would be great and address some of the issues expressed by some of the Linux folks who have somewhat hacky screen resolution change capabilities with AWT. You would want to solicit some assistance from the LWJGL folks from an API perspective. Even with JOGL it isn’t necessary to have AWT in the mix unless you want it there (though we’d have to do some Class.forName() stuff to make the linking work). If you do something similar to a createNativeGLWindow the native implementation simply spawns a window and uses that window for rendering. That’s doable but will require a little munging of the API implementation to make it work to the extent that LWJGL works since the native code compilers will barf if they run across AWT code floating around.

If I understand your question you’re trying to figure out how OpenGL on Windows handles double and triple buffering? On OSX (and I believe its still the same in windows) the buffer count is simply passed into the PIXELFORMATDESC that is used to create OpenGL, thereby transparently shielding you mostly from the implementation.

The call to swapBuffers() then just moves to the next buffer in the chain. But I’m not sure I totally understand your question.

But as to your other topic… it looks like I’ll have to expose my machine to the 10.3 Developer Preview sooner than I planned :slight_smile: I better go ahead and make sure everything is in CVS…

#4

GL.GL_XXXXX

This is an annoyance and the more that I type it, the more annoying it becomes :slight_smile: Is there no way we can get rid of this unnecessary GL.GL or gl.gl semantic?

#5

[quote]GL.GL_XXXXX
This is an annoyance and the more that I type it, the more annoying it becomes :slight_smile: Is there no way we can get rid of this unnecessary GL.GL or gl.gl semantic?
[/quote]
Agreed, its an annoying redundancy. Someone in the Jogl crew mentioned that it wouldn’t be too tricky to get the generation of the GL etc. classes to output gl.enable() style as basic wrappers for gl.glEnable style, so theres hope yet :slight_smile: Personally I think gl.glXXX() should be a wrapper around gl.XXX().

#6

Now for the moment of truth - now that we see we want to make this change, how do we effect this change. Do we have meetings, talk in a mailing list, vote, etc? Sun folks, please chime in! The weekend is coming and I have a lot that I want to get done :slight_smile:

#7

Please look into “JOGL Exposed” thread - it was covered there.

[quote]The names were left unchanged simply because all of the existing documentation and code refers to those names, and changing them would cause unnecessary confusion.
[/quote]

#8

Well the projects are very much run by the project leads (like most open source).

Until Dan, who I believe is lead ath the moment (is that right, Ken?) checks in I’d suggest this. Set up your workspace and dive in. My experience is its a lot harder to turn down a “gift horse” when its already done :slight_smile:

OR you could spend the wait time working on Mac JInput stuff… he said, dunning for his own project :wink:

JK

#9

There is no formal policy in place but my belief is that there should be consensus among the project owners before making changes like these. I am one of the owners (as well as the first author of JOGL) and would be disappointed if such changes were made without more discussion, in particular over email.

The GL.GL_ redundancy will go away in 1.5 with the introduction of static imports. There are concrete technical reasons for not using static imports to try to eliminate the gl.gl pattern which I will be happy to detail later this weekend if anyone is interested. As I’ve stated before, I believe that changing the method names from glXXX will only cause confusion.

I also think these are very minor syntactical issues and that there are other more pressing things to work on, including pbuffer support on X11 and Mac OS X, implementing sharing of display lists among contexts, and thinking about full-screen support directly in JOGL.

#10

I agree that these things are more important overall - but, contrary to any api-wide naming change, they can be done at any point in the future, independent of each other. On the other hand, possible renaming of all methods would have to be done ASAP.

But I think we got the message - you like them this way and as it is estetic argument, not technical, there is no real point to argue. For me, case is closed :slight_smile:

#11

Yeah, that’s really the reason I bring it up now. While many of us do own cool refactoring IDEs - it would be best to deal with something so close to the core code now before a lot of people start diving in and having large volumes of code to deal with. On this matter I think JOGL should follow LWJGL.

#12

Hurrah :slight_smile:

FYI there triple buffering is not available at all in OpenGL for Windows, end of story - this is due to the Windows GL/GDI layer just simply not allowing it. I don’t expect it to be available on Linux either but I don’t know.

Also FYI mixing OpenGL and DirectDraw / Direct3D is exceedingly bad and usually results in big trouble or the BSOD. Currently Webstart is causing LWJGL to barf on the latest ATI GL drivers which is annoying to say the least.

Cas :slight_smile:

#13

In regards to the conversations going on about how to make an API change. We are in the process of finishing up some docs on how we want to run the games projects. In this doc it will describe the process to make changes to an API. It is almost done, just need to addess a few more issues.

That being said, Sun has a mandatory shutdown next week (thanks to this great economy of ours) so it won’t be finished until the week after.

d

#14

Well I’m sure most of us are either on vacation or will just be taking a well needed break next week.

#15

Not me. For some reason the British don’t celebrate July 4th… ;D

#16

We’re all friends now :slight_smile: Come over to the states (Atlanta, GA specifically) and I’ll buy you a beer.