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
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.
(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.
Turns out not only glClear(..) causes this issue,
but also glDrawArrays(..).
In short, all target renderbuffer write commands seems to fail!
If skipping display in the shared master GearsES2 altogether,
no gl-error appears and the test is working.
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.
Set default framebuffer for OSX DummyDrawable,
hence enforce NSView realization for DummyDrawable.