On Fri Aug 1 15:33:17 2025 +0000, Brendan Shanks wrote:
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?
Thanks, I can indeed reproduce the breakage with your sample app and some other, as soon as child windows are being used.
But it turns out that my plan to replace winemac child surface management with something more similar to the other drivers also fixes that issue, it only needs to be in place prior to this code removal. I have updated the MR with the complete set of changes instead.