Enabling Stencil buffer breaks rendering (OSX, R11)?

If I add the following code:

caps.setDepthBits(24);
caps.setStencilBits(8);
caps.setAlphaBits(8);

to the createGLCanvas() function in the test case TestGLCanvasAWTActionDeadlock01AWT.java, then the rendering breaks. The output just consists in garbage left over in the buffers:

http://imgur.com/qetVY

The problem disappears if I remove the setStencilBits() call. This happens with R11 on OSX 10.8.2, and also using NEWT.

I see the following line:

// capabilities.setStencilBits(8); // No Stencil on OSX w/ hw-accel !

in TestGLCanvasAWTActionDeadlock02AWT. But the stencil buffer used to work on OSX until recently, as far as I remember...

On 11/11/2012 10:26 PM, ac [via jogamp] wrote:
> I see the following line:
>
> // capabilities.setStencilBits(8); // No Stencil on OSX w/ hw-accel !
>
> in TestGLCanvasAWTActionDeadlock02AWT. But the stencil buffer used to work on
> OSX until recently, as far as I remember...

Yes .. 'Huston, we have a problem' :)

Well, it doesn't generate the proper hw-accel GL context w/ onscreen AFAIK.
FBO does support depth/stencil.

We have to validate this behavior in a different unit test,
i.e. one of the *Capabilities* tests w/ AutoDrawable.

For sure .. there is something wrong.

~Sven

I can confirm that the stencil buffer stopped working for me after a recent OSX update. This is with an older version of JOGL (2.0-b57-20120502), but the only change was the OSX update, my app and JOGL stayed the same.

I was doing something simple enough that I could just play with the z buffer to get it done, so I didn't investigate.

Do you think this problem comes from a regression in the driver?

On 11/17/2012 03:08 PM, gouessej [via jogamp] wrote:
> Do you think this problem comes from a regression in the driver?

Difficult to say.

We can workaround this in case we use the FBO path,
i.e. dropping special GLCapability requests for the 'dummy' drawable.
I actually though we already do that - seems not the case.
Will have time this weekend for it.

~Sven

> Julien Gouesse
> http://tuer.sourceforge.net
> http://gouessej.wordpress.com

On 11/11/2012 10:33 PM, Sven Gothel wrote: Fixed yesterday w/
  <http://jogamp.org/git/?p=jogl.git;a=commit;h=7e5371ca8eafce28c242fa7fbd8aec045fc81b71>

Next builds will include the fix, maybe use the source 1st to validate.

~Sven

I confirm that the fix works on OSX 10.8.2. Thanks!

I found what it appears to be a regression caused by the fix. Querying the depth and stencil bits with glGetIntegerv (i.e: glGetIntegerv(GL_DEPTH_BITS, ...)), returns 0. tested with the autobuilds from Nov 25.

On 11/26/2012 08:50 PM, ac [via jogamp] wrote:
> I found what it appears to be a regression caused by the fix. Querying the
> depth and stencil bits with glGetIntegerv (i.e: glGetIntegerv(GL_DEPTH_BITS,
> ...)), returns 0. tested with the autobuilds from Nov 25.

Well, this is more of a 'transparency' bug of the FBO offscreen implementation
I am afraid.

Even before, the returned values didn't reflect the actually used ones of the FBO,
but of the attached dummy framebuffer.

The true values of depth and stencil are provided by the chosen GLCapabilities.
We may file this as a bug in general for FBO offscreen usage, or mark it as a disclaimer.

Ofc .. we could intercept this query and return the actual FBO value ..

On the other side, these queries are deprecated in GL 3.3 and n/a in ES2 anyways,
hence I would vote for a 'disclaimer' only.

In short: Use the chosen GLCapabilities, as valid _after_
the GL context became current the 1st time. The context would have been current for
the GL query anyways, hence it doesn't pose a restriction here.

~Sven

Ok, I think is better to use the depth and stencil  values from the chosen caps then. Thanks