Re: XWin can't hold OpenGL picture, has WS_DISABLED and WS_EX_TRANSPARENT styles?

I've put forward a patch (https://sourceware.org/bugzilla/show_bug.cgi?id=25170) to this for anyone interested. I'll explore putting it elsewhere, but I really think these mailing lists are an albatross, not sure I want to join another. - Original Message - > From: "M

Re: XWin can't hold OpenGL picture, has WS_DISABLED and WS_EX_TRANSPARENT styles?

#x27;t crash and does draw correctly other than it can't hold a picture. - Original Message - > From: "Mick Pearson" > To: "cygwin" > Sent: Saturday, November 9, 2019 3:49:12 AM > Subject: Re: XWin can't hold OpenGL picture, has WS_DISABLED and

Re: XWin can't hold OpenGL picture, has WS_DISABLED and WS_EX_TRANSPARENT styles?

P.S. Sorry to add, the WM_ERASEBKGND message occurred to me, or setting the class-background to the "null" brush is a likely culprit. It is behaving like a front-buffered old-fashioned application somewhat. Clipping and own-DC style should prevent damage, but I don't know, something seems to be r

XWin can't hold OpenGL picture, has WS_DISABLED and WS_EX_TRANSPARENT styles?

XWin has never had a permanent picture with OpenGL. Any movement "damages" all windows. I know I've looked at it before, but I checked its window/class styles with MS's Spy++ tool today. The normal styles that govern clipping and permanence look fine, but it has some weird styles that normally f

X: wglMakeCurrent error: 0006 on XUnmapWindow->XMapWindow

I was asked by the freeglut mailing list to alert the X/Cygwin team to problems with the WGL context handles becoming invalid if a window is hidden and then the error in the subject is out putted when the window is revealed again. There are also issues with iconification, where the windows are in