I found the commit that added the child views and it describes the issue pretty well (d91e568635c7cd23bd56f3ed688a2ba0b7219097), I don't know if there have been changes since then which make it unnecessary?
There's also an internal CodeWeavers bug for this general issue (9949) which links to http://www.alsprogrammingresource.com/opengl_mdi.html as an example that's problematic. I was able to rebuild that EXE, and the problem is still present (GL draws on top of the MDI window borders). Here's my modified source, and an EXE is included: [oglmdi2_bshanks.zip](/uploads/0323c1f97f80387aeb69e419946f2343/oglmdi2_bshanks.zip)
With this patch, the app crashes when I open a window: ``` Backtrace: =>0 0x7a53830f halveImage_ubyte+0xcf(components=0x3, width=<internal error>, height=<internal error>, datain=<is not available>, dataout=<is not available>, element_size=0x1, ysize=0x7ffc2000, group_size=0x3) [/Users/pip/wine/build64ntools/../dlls/glu32/mipmap.c:341] in glu32 (0x0022f884) 1 0x7a52b9ee gluBuild2DMipmapLevelsCore+0x9e8(userLevel=<internal error>, baseLevel=<internal error>, target=<internal error>, internalFormat=<internal error>, width=<internal error>, height=<internal error>, widthPowerOf2=<internal error>, heightPowerOf2=<internal error>, format=<internal error>, type=<internal error>, maxLevel=<internal error>, data=<internal error>) [/Users/pip/wine/build64ntools/../dlls/glu32/mipmap.c:3839] in glu32 (0x0022f9d8) 2 0x7a52b9ee gluBuild2DMipmaps+0xb0e(target=<couldn't compute location>, internalFormat=<couldn't compute location>, width=<couldn't compute location>, height=<couldn't compute location>, format=<couldn't compute location>, type=<couldn't compute location>, data=<couldn't compute location>) [/Users/pip/wine/build64ntools/../dlls/glu32/mipmap.c:4410] in glu32 (0x0022f9d8) 3 0x0040da70 in oglmdi2 (+0xda70) (0x0022fa70) ```
I'm not sure what the ultimate fix would be for this kind of GDI/OpenGL layering issue--have each Cocoa/GDI child window draw its own content? (Possibly combined with having OpenGL content draw into an IOSurface-backed texture rather than taking over an NSView?) Or Wine having a compositor itself that draws everything?