OpenGL rendering fallback
Andrew Brygin
andrew.brygin at oracle.com
Fri Dec 16 20:39:18 PST 2011
Hello Scott,
I have played with the capability to fall-back to software renderer
some time,
and found that attribute NSOpenGLPFAFullScreen prevents the smooth
fall-back.
For example, if you explicitly request the software renderer, i.e. use
attribute
NSOpenGLPFARendererID, kCGLRendererGenericFloatID
instead of
NSOpenGLPFAAccelerated
then you get the same startup crash as it is described in MACOSX_PORT-107
But, if we remove the attribute NSOpenGLPFAFullScreen as well, then
the pixel
format object initializes correctly.
The sad part of the story is that on 10.7 systems, usage of the
software renderer
causes heavy rendering artifacts in CAOpenGLLayer, which is used in
java by default.
Jira issue MACOSX_PORT-669 describes this problem. However, the same
configuration
(software renderer + CAOpenGLLayer) works fine on 10.6. In order to
verify this,
I have modified CALayerEssentials demo to request software renderer
explicitly,
and have reproduced the same rendering problem. So ,I tend to think
that here
we have faced with a bug in layers support in 10.7. The only option to
workaround it
would be disabling support of CAOpenGLLayer in java, but, as far as I
know, this is
mandatory feature for plugin, and it can not be disabled.
Thanks,
Andrew
On 17.12.2011 4:39, Scott Kovatch wrote:
> Folks,
>
> We're trying to get our nightly builds for the deploy stack to run automated tests via Hudson. Before I go through the hoops of setting up Hudson, changing the build configuration, etc. I tried running them via screen sharing and using a virtual/remote desktop for a user not logged in at the remote system. However, I ran into http://java.net/jira/browse/MACOSX_PORT-107, which is a startup crash in OpenGL.
>
> After a lot of debug building and j2d debug logging I found that the problem was that we were failing to create an NSOpenGLPixelFormat object, bailing out, and not checking the result in CGLGraphicsConfig.getConfig(). I added "if (cfginfo != 0)" before calling getOGLIdString, but that just prevented a native crash; it still led to an NPE creating windows.
>
> So, I saw this code:
>
> NSOpenGLPixelFormatAttribute attrs[] = {
> NSOpenGLPFAClosestPolicy,
> NSOpenGLPFANoRecovery,
> NSOpenGLPFAAccelerated,
> NSOpenGLPFAFullScreen,
> NSOpenGLPFAWindow,
> NSOpenGLPFAPixelBuffer,
> NSOpenGLPFADoubleBuffer,
> NSOpenGLPFAColorSize, 32,
> NSOpenGLPFAAlphaSize, 8,
> NSOpenGLPFADepthSize, 16,
> NSOpenGLPFAScreenMask, glMask,
> 0
> };
>
> and I have to ask if it's absolutely necessary that we be this restrictive when creating an OpenGL context. Basically, if we can't get a fully hardware-accelerated renderer we just give up and return.
>
> The docs for NSOpenGLPixelFormatAttribute say "This attribute is not generally useful". I think that's an understatement here. :-)
>
> I did some experimenting with these options and I can get my tests to run in a screen-sharing window, but then the contents of the window don't draw, so I'm clearly getting out of my area of knowledge here.
>
> Any help would be appreciated.
>
> -- Scott K.
>
More information about the macosx-port-dev
mailing list