Hello, i was asking a lot on this forum about why arent my hardware capabilities captured correctly when i use GLCapabilies.
As i was seeking an answer to this, i started digging into the code of RC8 (Latest release) and i would appreciate if some one could explain the folowing.
The constructor of GLCapabiities (which according to 1.1.0 javadocs detects the best configuration that my hardware can provide) does nothing :
ublic class GLCapabilities implements Cloneable {
private boolean doubleBuffered = true;
private boolean stereo = false;
private boolean hardwareAccelerated = true;
private int depthBits = 24;
private int stencilBits = 0;
private int redBits = 8;
private int greenBits = 8;
private int blueBits = 8;
private int alphaBits = 0;
private int accumRedBits = 0;
private int accumGreenBits = 0;
private int accumBlueBits = 0;
private int accumAlphaBits = 0;
// Shift bits from PIXELFORMATDESCRIPTOR not present because they
// are unlikely to be supported on Windows anyway
// Support for full-scene antialiasing (FSAA)
private boolean sampleBuffers = false;
private int numSamples = 2;
// Bits for pbuffer creation
private boolean pbufferFloatingPointBuffers;
private boolean pbufferRenderToTexture;
private boolean pbufferRenderToTextureRectangle;
/** Creates a GLCapabilities object. All attributes are in a default
state.
*/
public GLCapabilities() {}
The instance of this GLCapabiites should be passed to the GLCanvas which will on construction try to get the best set of capabilities close to the capabilities requested by the user!
The GLCanvas will call chooseGraphicsConfiguration(capabilities, chooser, device); which will query the hardware for the capabilites
public GLCanvas(GLCapabilities capabilities,
GLCapabilitiesChooser chooser,
GLContext shareWith,
GraphicsDevice device) {
// The platform-specific GLDrawableFactory will only provide a
// non-null GraphicsConfiguration on platforms where this is
// necessary (currently only X11, as Windows allows the pixel
// format of the window to be set later and Mac OS X seems to
// handle this very differently than all other platforms). On
// other platforms this method returns null; it is the case (at
// least in the Sun AWT implementation) that this will result in
// equivalent behavior to calling the no-arg super() constructor
// for Canvas.
/*
* Workaround for Xinerama, always pass null so we can detect whether
* super.getGraphicsConfiguration() is returning the Canvas' GC (null),
* or an ancestor component's GC (non-null) in the overridden version
* below.
*/
super();
/*
* Save the chosen capabilities for use in getGraphicsConfiguration().
*/
chosen = chooseGraphicsConfiguration(capabilities, chooser, device);
if (chosen != null) {
/*
* If we are running on a platform that
* must select a GraphicsConfiguration now,
* save these for later use in getGraphicsConfiguration().
*/
this.glCapChooser = chooser;
this.glCaps = capabilities;
}
if (!Beans.isDesignTime()) {
drawable = GLDrawableFactory.getFactory().getGLDrawable(this, capabilities, chooser);
context = (GLContextImpl) drawable.createContext(shareWith);
context.setSynchronized(true);
}
}
Tracking this function down will lead to three implementations depending on your OS (MacOSX, X11, Windows)
Windows (WindowsGLDrawableFactory):
public AbstractGraphicsConfiguration chooseGraphicsConfiguration(GLCapabilities capabilities,
GLCapabilitiesChooser chooser,
AbstractGraphicsDevice device) {
return null;
}
MacOSX (MacOSXGLDrawableFactory):
public AbstractGraphicsConfiguration chooseGraphicsConfiguration(GLCapabilities capabilities,
GLCapabilitiesChooser chooser,
AbstractGraphicsDevice device) {
return null;
}
X11 is the only one that does actualy something and doesnt return null!
Why is that ? And doesnt this mean that there is no querying of hardware capabilities on windows and MacOS unlike what JOGL says?
Regards,
Rami
.