Repository navigation
Release the WebGL context when a video processor is destroyed - #144
Merged
Merged
Conversation
VideoTransformer.destroy() now calls WEBGL_lose_context.loseContext() via a new releaseContext() on the setupWebGL pipeline, so each attach/detach cycle no longer leaves a context alive until GC (#136). - Kept out of cleanup(): restart() runs cleanup() then setupWebGL() on what can be the same canvas, and a lost context stays bound to its canvas. - BackgroundTransformer.destroy() closes the MediaPipe segmenter, which shares the canvas's context, before super.destroy() releases it. - Optional chaining leaves the context to GC where the extension is missing. Adds a unit test pinning cleanup() vs releaseContext() and e2e test B3, which fails without the fix.
🦋 Changeset detectedLatest commit: 5b038be The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
1egoman
approved these changes
Oct 20, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Summary
Fixes #136. Each
setProcessor/stopProcessorcycle left one WebGL context alive until garbage collection. Chrome caps live contexts per GPU process at around 16.VideoTransformer.destroy()now releases the context withWEBGL_lose_context.loseContext(), through a newreleaseContext()on thesetupWebGLpipeline.Why not just call
loseContext()incleanup(), as the issue suggestsVideoTransformer.restart()runscleanup()and thensetupWebGL()on what can be the same canvas. A lost context stays bound to its canvas, andgetContext()returns it again, so restart would break. The release is therefore a separate step that onlydestroy()calls.ProcessorWrapper.restart()is unaffected becauseinit()always creates a new canvas.ImageSegmenteris given the same canvas, so it renders into the same context.BackgroundTransformer.destroy()now closes the segmenter beforesuper.destroy()releases the context. It also setsisDisabledbefore thatawait, so frames that arrive during the close are passed through.getExtension(...)?.loseContext()does nothing when the extension is unavailable, which leaves the context to GC as before.ProcessorWrapper's lifecycle state already guards against it.VideoTransformer.destroy()is synchronous and clearsthis.gl, so a second call does nothing.Tests
cleanup(), can be set up again on the same canvas, and is lost afterreleaseContext().workers: 1in the e2e config is left as is. MediaPipe still creates contexts of its own, so raising it should be a separate check.