Description

Hi.

The first time when an offscreen OpenGL context is created with GHOST_ContextCGL::createOffscreenContext(), glClear(GL_COLOR_BUFFER_BIT) is called while glCheckFramebufferStatus(GL_FRAMEBUFFER) is GL_FRAMEBUFFER_UNDEFINED, resulting in an glError in GHOST_Context::initClearGL().

When a new window with an (onscreen) OpenGLContext is created, initClearGL() is OK, because makeCurrentContext did set the gl-context.

I think a better solution would be to move the gl-commands (initClearGL and flushBuffer) to another part in the initialization, after GHOSTContextCGL::activateDrawingContext() is called, so every operating system has the same initialization. This requires more code-refactoring, creating possible bugs at other operating systems, and I can only test MacOS.

Removing both initClearGL() and [m_openGLContext flushBuffer] from GHOST_ContextCGL::initializeDrawingContext() in a simple test didn't show any errors (for both on- and offscreen gl-contexts) and it looks like everything is still working OK.

I think fix #1 is simple, solves at least a single glError and doesn't break anything. Not sure if [m_openGLContext flushBuffer] should also be disabled when creating an offscreen gl-context, but the flushing would be useless when nothing is done on this gl-context, right?

Both possible fixes in #1 (version 1a or 1b) don't generate a glError.

Also fix #2 (remove both functions for on- and offscreen context) don't generate a glError.

Not only is the unexpected attribute a problem, the other values were never defined anywhere in Blender so it is done by OSX.

When [m_openGLContext flushBuffer] is called, it internally calls CGLChoosePixelFormat().

After disabling flushBuffer, the same would happen when swapBuffers() is called.

On the more recent OSX version, all views are layer-backed views. (Also the end of subpixel antialiasing for fonts, which is noticeable on non-retina screens).

All NSView-classes automatically use the CALayer for drawing and NSView would handle the rest (Events etc.). So in reality, everything is offscreen-rendering and OSX can apply their own effects (like the bottle-minimizing-window-effect).

My suggestion would be to remove NSOpenGLView and NSOpenGLContext completely, since Apple gave tips in 2011 on how to port your code from NSOpenGLContext to CGLContextObj.

and some changes to keep using the NSGLOpenGLContext as it is right now.

(I probably should have added CGLReleasePixelFormat() or CGLDestroyPixelFormat(), but that isn't a big issue for now and it isn't documented very well either and those mem-leaks would be minimal, but must be noted. Releasing too much would definitely break things, and I don't know the retain cycle in this case.)

Maybe clearing is not needed at all for an offscreen context though. We do that to show something in the window before the Blender UI is fully loaded, but for an offscreen context it does not matter.

In the error case at the end of the function, it's also restoring prev_openGLContext in m_openGLView, but that's no longer correct if that's not what we're getting it from anymore. As far as I can tell the only place where goto error happens is when we haven't modified the view though, so perhaps the code can be removed.

Maybe a crazy idea now: Apple promotes their own Metal framework, but this can be mixed with OpenGL. Maybe the onscreen-buffer can be pushed into the Metal buffer and let them handle the rest. Lots of 'maybes', but maybe?