There are good reasons for not exposing public constructors but instead using the Factory Method design pattern, including being able to substitute a subclass for the class being instantiated if it turns out to be desirable to do so in the future. It’s for this reason that we preserved the GLDrawableFactory as the means for instantiating all OpenGL drawables. You can always feel free to subclass GLCanvas and provide your own public no-arg constructor.
JSR-231 has reached the Public Review phase. Please see the JSR’s home page:
http://www.jcp.org/en/jsr/detail?id=231
Thank you all for your valuable feedback during the Early Draft Review phase. We expect that because of all of the good feedback that the API should be fairly stable at this point. Nonetheless, we would appreciate any comments you have on the specification.
The nightly build on the JOGL home page reflects the current state of the proposed Reference Implementation. There is some work going on behind the scenes to make the autogenerated code more robust, and we are waiting to release JSR-231 beta 2 until that work is done. However, we do not anticipate any public API changes between now and beta 2.
Please look at the proposed specification and post any comments you have. The Public Review period is scheduled to last roughly a month.
Happy holidays and New Year to you and yours.
I was just casually browsing the docs:
- Threading still mentions JOGL, and uses jogl properties (JOGL is also mentioned in other places). Should probably just be called RI ?
- DebugGL and TraceGL shouldn’t be part of the jsr (IMO)
- No support for AWT Panel ?
- opengl.factory.class.name should probably be javax.media.opengl.factory.class.name ?
- not sure why there is a need for the AWTGraphics<Configuration|Device>
Will Javadoc be added to methods or ?
we tried it once, but it gave a lot of issues with IDE’s because there is so much man page info that can be added.
Thanks for pointing this out; I’ve removed all of these references. The changes will show up once the nightly builds are back on-line; it looks like they were disabled due to build breakage just before the holidays.
The expert group voted to keep these in the API. They add relatively little to the download size and having them ubiquitously present adds great value. There are also historical precedents for including them, e.g. javax.swing.DebugGraphics.
What do you mean? The intended use of the GLDrawableFactory chooseGraphicsConfiguration and getGLDrawable APIs was with AWT Canvases, but someone on these forums just discovered that at least the getGLDrawable API works just fine with any AWT heavyweight such as a Frame. The specs don’t restrict the use to just Canvases, although they are phrased using Canvas as an example, and the implementation also has no such restriction.
The AWT Panel also does not support selection of an arbitrary GraphicsConfiguration as the Canvas class does. This is important on X11 platforms.
There are examples of other properties with abbreviated names such as -Dawt.toolkit=… and -Dswing.foobar=… . Since there’s no convention on property names I think using a shorter name is fine.
This removes a direct dependence on the AWT from the GLDrawableFactory’s chooseGraphicsConfiguration API and (at least in theory) allows it to work with the SWT. I’m not sure whether Justin Couch’s experimental SWT port actually uses that API on X11 platforms.
For this reason as well as just resource constraints we have no plans to add the man page information into the automatically-generated javadoc. If we could figure out a good way to generate links to the opengl.org man pages I’d do it. However it’s my understanding that even that documentation is pretty far out of date. I could be wrong about this.
in the previous net.java.games.jogl.util.BufferUtils, there’s a method called .bufferOffset(int) that is not present in the new BufferUtils class… The Xith JOGL renderer uses this method (in ShapeAtomPeer) together with glColorPointer and the other gl client arrays…
I’m not used with this method and don’t understand yet its usage, … so what is it for, and what’s the recommended way of porting it to the jsr231 release ?
Many thanks,
Lilian
This used to be how JOGL exposed Vertex Buffer Object support. Due to security reasons it was necessary to stop doing this and instead generate an overloaded entry point for every function affected by the VBO/PBO extensions. This is similar to how LWJGL has been exposing the VBO/PBO entry points. You will find a glColorPointer taking a long buffer_offset argument which is the one you should call when VBO support is enabled. The argument to that function is the same argument you used to pass to BufferUtils.bufferOffset().
Re naming: surely it would be more appropriate to use net.java.opengl.util rather than com.sun.opengl.util - or is it intended that Sun will produce and own all code in that package (i.e., no community contributed texture loaders, etc…)?
JSR-231 beta 2 has been released on January 4, 2006. This release is intended to follow the Public Review status of the JSR.
There have been some public API changes since beta 1. The GLDrawableFactory’s chooseGraphicsConfiguration API has been changed to support ports to other toolkits than the AWT. The constructors for GLCanvas and GLJPanel have been made public, and the factory methods on the GLDrawableFactory for creating them have been removed. This makes the GLDrawableFactory API simpler and focuses it more on its core task of binding GLDrawables to arbitrary widgets. There have been other minor changes to the GLU API and bug fixes to its implementation. A certain amount of size checking for Buffers has been added to the implementation, in particular to the APIs for setting up textures. Such size checking has been present in the LWJGL library for some time now, and its presence will catch many of the kinds of crashes which were seen when switching from JOGL 1.1.1 to the JSR-231 APIs in which Buffers’ positions are significant. We do not anticipate any noticeable slowdowns on any applications due to the presence of this error checking. It is currently fairly rudimentary and not quite precise but we hope to improve it in the future.
Thanks to Lilian Chamontin (c_lilian) the new JOGL Applet Launcher has finally been deployed in this release! This class enables the deployment of unsigned applets using JOGL with no manual installation of any software on the end user’s machine. All that is required is that the end user accept a certificate from Sun Microsystems, Inc., which is also required when launching unsigned JOGL-based applications via Java Web Start. This tool represents a great step forward in deployment possibilities and we are very grateful to Lilian for her hard work and contribution. There is a new JOGL applet test linked from the JOGL demos page.
We believe that the current API and implementation are in good shape to become the official reference implementation of JSR-231. Some work is still planned but is mostly cleanup work (i.e., adding versioning), documentation and adding of some utility classes not covered by the JSR-231 spec.
The new build is available in the Documents and Files section of the JOGL home page. The JOGL demos have been updated to use the new binaries. Please try it out (or try the current nightly build on the JOGL home page) and post with any comments, questions or problems.
There is no such intention. The namespace is not really relevant and was chosen to parallel the com.sun.j3d.utils namespace in the Java3D world. Contributions are gladly accepted under the terms of the contributor agreement on the JOGL home page. All of the code in the JOGL project is licensed under the BSD license or equivalent (in the case of code from other projects). We do restrict direct putbacks to the workspace to a limited number of developers, but anyone is welcome to join the development process by contributing patches, etc. and we usually approve requests for developer status by those individuals who have made strong contributions.
A bug was found in the JOGLAppletLauncher on Solaris/x86 by Travis Bryson from Sun which required a new build of JSR-231 beta 2’s jogl.jar to be pushed. This has been done; if you downloaded the jar file yesterday, please download it again.
Hmm I’d like to clarify this point… in France, Lilian is for boys, and Liliane is for girls 
Otherwise, great news, and I’m looking forward to showcase my new applet game, featuring Xith3D and jsr231 (beta release of the game in a few days).
Lilian
So, would it be a good idea to add the javadoc to the release build?
The javadocs are the contents of the public reviewed zip for JSR231.
Whooops. Sorry about that. Cultural differences and my own ignorance. I hope I didn’t make this mistake in the documentation. Actually I just checked and fortunately I didn’t.
Cool. Please post when it’s available. We need to put up a project page linking to all of the cool stuff people are writing.
turquoise3232 is correct, but there is a stupid legal reason why we don’t distribute a zip archive of the javadoc, which is that officially we need to implement a click-through license for it. We’ve worked around this for the time being by putting the unzipped javadoc from the nightly builds on the JOGL home page.
How do GLDrawable#createContext and GLAutoDrawable#getContext interact? In other words, if I have a GLAutoDrawable instance that has created its own context and later on I call createContext on this instance, will this cause problems? The same question goes for calling createContext multiple times on a GLDrawable instance.
There are no problems with doing this. The GLAutoDrawable implementations simply automatically call createContext() once, hold on to the result internally, and return it whenever getContext() is called. It is legal to create another context for a GLAutoDrawable or for any arbitrary GLDrawable. The demos.context.DualContext demo shows one possible use of the createContext API, though it doesn’t call it on a GLCanvas but a custom Canvas subclass.
JSR-231 beta 3 has been released on February 17, 2006. This release is intended to match the Proposed Final Draft status of the JSR. You can download the binaries from java.net.
In the JSR-related APIs, there is one incompatible change:
[] The setOffscreen methods in GLCapabilities have been renamed to setPbuffer* for clarity.
There are also some changes to the javadoc which do not impact compatibility:
[] Removal of many implementation-specific references in the specification, or called them out explicitly as applying only to the reference implementation and not to the specfication or implementations in general. Clarification in various API areas.
[] Added overview section on context sharing
[] Added overview section on runtime version information
[] Changed name of properties in Threading class that contained “jogl”
In the non-specified APIs (in particular, the helper routines under com.sun.*), several changes have been made:
[] The namespace com.sun.opengl.utils. was renamed to com.sun.opengl.util.* and several class names were changed from plural to singular to more closely match the naming convention in the core platform.
[] By popular demand, control over gamma, brightness and contrast has been exposed under the com.sun.opengl.util.Gamma class.
[] Some more routines were added to the Screenshot and ImageUtil classes to support taking snapshots containing alpha channels.
[] Brian Paul’s tile rendering library has been ported to Java by user bleb here on the forums and, with Brian’s permission, incorporated into com.sun.opengl.util. This utility makes taking print-quality screenshots very simple. A demo has been incorporated under demos.misc.TiledRendering in the jogl-demos workspace.
[] A few more JOGL demos have been incorporated including picking using the selection buffer and writing a custom GLCapabilitiesChooser.
[*] Additional minor changes and bug fixes.
Going forward we do not anticipate any more incompatible API changes. This last round of changes was done to achieve better consistency and clarity in the APIs before they are finalized.
There are more plans to change the implementation to be more scalable in particular on multi-head X11 systems, but these changes will not impact the public API.
Please try the new builds and post with any comments or problems. Thanks.
Yaaay! Nice.
To quote a very wise man:
“Freakin’ sweet!” - Peter Griffin, 1999
Succes after the renaming changes except for the apparent lack of:
com.sun.opengl.util[s].Version
Is there an eguivalent function?