The title says it all: the pixel format used by MonoMacGameView has a depth size of 16-bit instead of 24-bit like XNA, which may cause z-fighting (and does in my case).
The 16-bit depth size is hard-coded in https://github.com/mono/monomac/blob/master/src/OpenGL/MonoMacGameView.cs#L66 so I guess someone should submit a pull request there to make it customizable? (they don't have GitHub Issues enabled on the repository)
I worked around it in my own code by copying part of the MonoMacGameView's constructor at the top of MonoGame's MacOS/GameWindow class and using some reflection to update private fields (but this means the OpenGL context gets created twice):
// Force 24-bit depth size (like XNA) instead of MonoMacGameView's 16-bit depth size
object attribs = new object
var pixelFormat = new NSOpenGLPixelFormat (attribs);
var pixelFormatFieldInfo = typeof(MonoMacGameView).GetField( "pixelFormat", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic );
pixelFormatFieldInfo.SetValue( this, pixelFormat );
var openGLContext = new NSOpenGLContext( pixelFormat, null );
var openGLContextFieldInfo = typeof(MonoMacGameView).GetField ( "openGLContext", System.Reflection.BindingFlags.Instance | System.Reflection.BindingFlags.NonPublic );
openGLContextFieldInfo.SetValue( this, openGLContext );
If this is deemed a good enough workaround for now, I can submit a pull request.
FWIW, XNA supports both 16 and 24 bit depth buffers according to the XNA programming references that I have. If your hardware supports 24 then maybe it can start there, but if you hard code it at 24 and the hardware only supports 16, then we'll get more of the partial frambuffer attachment errors, or even invalid state errors.
Oh right, the DepthFormat enum does have a 16-bit depth size (http://msdn.microsoft.com/en-us/library/microsoft.xna.framework.graphics.depthformat(v=xnagamestudio.10).aspx). Are there any supported OS X devices that can't do 24-bit depth though?
I also don't know what happens if the requested depth size can't be satisfied when creating the NSOpenGLContext, maybe we can test for it and revert to 16-bit otherwise? Or request the appropriate size based on the PreferredDepthFormat right away? (But is the PreferredDepthFormat always set before the window gets created?)