Bug 1087 - OSX 10.9.5 - default framebuffer write causes GL_INVALID_FRAMEBUFFER_OPERATION on dummy drawable
Summary: OSX 10.9.5 - default framebuffer write causes GL_INVALID_FRAMEBUFFER_OPERATIO...
Status: RESOLVED FIXED
Alias: None
Product: Jogl
Classification: JogAmp
Component: macosx (show other bugs)
Version: 2
Hardware: pc_x86_64 macosx
: --- major
Assignee: Sven Gothel
URL:
Depends on:
Blocks:
 
Reported: 2014-10-04 04:48 CEST by Sven Gothel
Modified: 2014-10-08 08:32 CEST (History)
0 users

See Also:
Type: ---
SCM Refs:
1fcfd014ca90125ab53ebc4e96e133535a55f095
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2014-10-04 04:48:10 CEST
Test case 
  TestSharedContextVBOES2NEWT1.test03EachWithAnimatorSharedOffscreen()
and similar start failing on OSX after update to 10.9.5 (?).

Test case uses a shared master context on a dummy onscreen drawable
created via factory.createDummy[Auto]Drawable(..).

The GLEventListener issues 
  glClear(GL.GL_COLOR_BUFFER_BIT | GL.GL_DEPTH_BUFFER_BIT)
and the OpenGL driver set the error state to 
  GL_INVALID_FRAMEBUFFER_OPERATION

+++

This happens with the Nvidia driver (discrete)
as well as with the Intel driver (integrated).

This happens on a Mac-Mini (Nvidia)
as well as on a Macbook pro (Intel+Nvidia).

+++

We have to investigate, 
whether the dummy onscreen drawable's invisible surface 
is no more suitable, or we have a other issues.

This could as well be a driver bug.
Comment 1 Sven Gothel 2014-10-04 04:49:29 CEST
(In reply to comment #0)
> 
> This could as well be a driver bug.

i.e. an OpenGL bug of Apple's generic 
OpenGL layer - utilizing the lower level vendor implementation.
Comment 2 Sven Gothel 2014-10-04 05:04:53 CEST
Turns out not only glClear(..) causes this issue,
but also glDrawArrays(..).

In short, all target renderbuffer write commands seems to fail!
Comment 3 Sven Gothel 2014-10-04 05:19:04 CEST
If skipping display in the shared master GearsES2 altogether, 
no gl-error appears and the test is working.
Comment 4 Sven Gothel 2014-10-05 04:26:24 CEST
After triaging, issue turns out to write into the default framebuffer,
i.e. onscreen NSView, while not having created the NSWindow/NSView (deferred)
and not having associated the NSView w/ NSOpenGLContext.

Hence we may describe the new issue w/ 10.9.5 as:
  GL_INVALID_FRAMEBUFFER_OPERATION and crash writing to default framebuffer
  w/o associating a realized NSView to NSOpenGLContext.
Comment 5 Sven Gothel 2014-10-08 08:26:32 CEST
1fcfd014ca90125ab53ebc4e96e133535a55f095

Set default framebuffer for OSX DummyDrawable, 
hence enforce NSView realization for DummyDrawable.