06-26-2018, 09:53 AM
I'm sorry for your troubles, Gaxx. We don't use OpenGL for anything internally so this issue is outside our wheelhouse.
Under the hood, the CustomWidget class utilizes MFC to perform its various tasks. MFC is really just a thin C++ wrapper around the Win32 API, so in order to perform drawing we simply respond to the WM_PAINT message. There is very little overhead during our WM_PAINT processing; we effectively just perform a little accounting (i.e. store which widget is currently drawing), get the current platform drawing context (so the class consumer can acquire it later via the CustomWidget::platformDC() method), execute the class consumer's drawing callback, and finally release the platform drawing context. The underlying platform control is created through a standard call to MFC's CWnd::Create() method (itself just a wrapper for Win32's CreateWindow() function).
Given our standard and straightforward use of the MFC API, and given that this problem with OpenGL suddenly appeared after a Windows 10 update, we can draw no other reasonable conclusion than the root culprit being some underlying change in Windows (or a possible change in Illustrator in response to the Windows 10 update, since we are running inside the context of Adobe's executable).
Lastly, we never explicitly wrote our CustomWidget class with the intention of interoperation with OpenGL, and do not use any such functionality ourselves. In fact, upon learning that some consumers of hdi_core were using OpenGL with the CustomWidget class, we were surprised and considered it a "happy accident". Our suggestion is to utilize Win32 or MFC platform code to create your own platform control inside the target window, such that you can manage/maintain all of the functionality of your widget for optimal interoperability with OpenGL.
Under the hood, the CustomWidget class utilizes MFC to perform its various tasks. MFC is really just a thin C++ wrapper around the Win32 API, so in order to perform drawing we simply respond to the WM_PAINT message. There is very little overhead during our WM_PAINT processing; we effectively just perform a little accounting (i.e. store which widget is currently drawing), get the current platform drawing context (so the class consumer can acquire it later via the CustomWidget::platformDC() method), execute the class consumer's drawing callback, and finally release the platform drawing context. The underlying platform control is created through a standard call to MFC's CWnd::Create() method (itself just a wrapper for Win32's CreateWindow() function).
Given our standard and straightforward use of the MFC API, and given that this problem with OpenGL suddenly appeared after a Windows 10 update, we can draw no other reasonable conclusion than the root culprit being some underlying change in Windows (or a possible change in Illustrator in response to the Windows 10 update, since we are running inside the context of Adobe's executable).
Lastly, we never explicitly wrote our CustomWidget class with the intention of interoperation with OpenGL, and do not use any such functionality ourselves. In fact, upon learning that some consumers of hdi_core were using OpenGL with the CustomWidget class, we were surprised and considered it a "happy accident". Our suggestion is to utilize Win32 or MFC platform code to create your own platform control inside the target window, such that you can manage/maintain all of the functionality of your widget for optimal interoperability with OpenGL.