Closed thomasmfish closed 2 years ago
One other option that may be preferable is to change all Destroy
s to Close(True)
s, then capture EVT_CLOSE
instead of EVT_WINDOW_DESTROY
, as EVT_CLOSE
is before the window is destroyed, so should avoid any timing issues when it comes to deleting GL textures. Would that be preferable to allowing PyOpenGL to handle the deletion automatically?
Another option is using the run in main thread decorator (sorry I can't remember exactly what it is called) which a lot of the openGL stuff actually uses to prevent thread classes, although if the destroy isn't needed then definitely a better plan to remove it.
From what I can see, when the context is deleted, anything that's exclusively assigned to it is also deleted. That does rely on Python to garbage collect though, so it's no bad thing to manually do it (unless there is a conflict like this). I can give the main thread a go and see if that fixes it.
That doesn't fix it, not sure what is going on in that case. Using EVT_CLOSE
also doesn't help. For whatever reason, glDeleteTextures
in freetype.py just breaks things.
Just played with this with the the simulation mode on my mac and it seems to solve the issues. Does this work for you and should I just pull it?
This is the call that is causing the issues with the mosaic, though I'm not clear about why.
From what I can tell, there's no need to use
glDeleteTextures
on window close as textures that are exclusive to a context are automatically deleted with the context anyway. I'm assuming the frequent (but inconsistent) mosaic issues are due to timing often causing duplicate calls toglDeleteTextures
, causing some break in OpenGL. As the mosaic would be the next obvious OpenGL update, that's where I noticed an issue. That could also explain why it often worked better the first time I ran Cockpit after checking out a different commit, as the pycache wouldn't have been updated, slowing down the call.Closes #787