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