Created attachment 861 [details]
Self contained test case
Self-contained test case has been distilled from the JaamSim project:
- creates separate render thread
- inits gl caps and a dummy drawable to set up a context
- first call to glCreateShader blows up on MacOS, is fine on windows.
I've left the read of the actual vertex shader code, but it currently crashes before actually doing anything with the shader source. So it doesn't actually matter what the contents of the shader are.
Created attachment 862 [details]
vertex shader code
Created attachment 863 [details]
non core context shader
I haven't yet validated the test case against the failures we observed in jaamsim, but from the jaamsim side this test case was distilled from:
v2.4.0-rc-20200202 - works just fine
v2.4.0-rc-20210111 - glCreateShader crashes with error 1286 which is FrameBuffer not ready
v2.5.0 fails on intel macs and M1/M2 based macs with same error code
Some resolution to this:
We were using the following to get a dummy drawable previously, this works fine on windows, but on MacOS for some reason the context returned from getContext had no framebuffer bound by default, causing the call to glCreateShader to error, glCheckFramebufferStatus returns gl_framebuffer_undefined.
dummyDrawable = GLDrawableFactory.getFactory(glp).createDummyAutoDrawable(null, true, caps, null);
We've moved to just creating an offscreen drawable which returns a context that does have a framebuffer bound.
dummyDrawable = GLDrawableFactory.getFactory(glp).createOffscreenAutoDrawable(null, caps, null, 16, 16);
(In reply to Harvey Harrison from comment #4)
Indeed that is exactly as both API entries shall behave,
i.e. 'dummy' implies not necessarily creating a usable surface (FBO or otherwise)
and 'offscreen' implies a usable surface (usually FBO).
And I found my commit where I have tightened the 'dummy' implementation
to favor a surfaceless context to query information.
Date: Sat Mar 4 19:57:39 2023 +0100
GLDrawableFactoryImpl:createDummyDrawable(): Similar to createOffscreenDrawable() prefer createSurfacelessImpl() over createDummySurfaceImpl() to reduce resources (no actual window)
This enhances the 'dummy drawable' use-case implementation, i.e. for shared context.