Delete OpenGL objects on regular drop instead of explicit destroy in glow example #7046
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is equally a question and a change suggestion: Can I retain a clone of the
Arc<glow::Context>
and use it to deallocate OpenGL objects on drop, instead of having to explicitly listen to theon_exit
event and pass that down from my top levelApp
to all subcomponents that have allocated OpenGL objects?I'm no OpenGL expert by any means. But from what I can find, OpenGL objects are tied to the contexts they were created under. So it would be surprising if the call to the
destroy
method had another context, than the one we got passed to us on initializiation? And if we always get the same context over and over, is there any reason why we can't just keep our own reference to it internally instead?This is slightly related to #5285. But instead of dealing with the explicit destroy of the
Painter
in the library, it deals with examples, showing howegui
users should deallocate their OpenGL objects.Opening the PR as a draft, since I'm not 100% this solution is valid.