I don’t think this is something we can easily fix in the MessageManagerLock - the lock causing the deadlock is in the CVDisplayLink code which is waiting for the CVDisplayLink thread to finish it’s callback before closing the display due to a display configuration change. This thread is doing the OpenGL rendering and takes a MessageManagerLock which is waiting on the main thread.
Short of removing all the MM locks from the OpenGL rendering code, which would be a huge rewrite, the next best fix is probably to revert to doing the actual rendering on a ThreadPoolJob (as it does on other platforms where we don’t have the CVDisplayLinkCallback driving the rendering) and just use the CVDisplayLinkCallback to wake up the job when it needs to render. We’ve added this in 281ae0b which fixes the deadlock, but now there is the issue of the rendering not being directly tied to the display callback as it was before. From some brief tests, the cost of waking up the rendering job which is just waiting indefinitely on the repaintEvent is minimal and shouldn’t cause sync issues, but it would be interesting to see if anyone encounters any issues with this change. I know that @yairadix proposed the change initially so would be interested to hear his thoughts on it.