Fix 288ms UI hang in video publishing flow #838
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.
🔗 Issue Links
N/A - Performance improvement identified through profiling
🎯 Goal
Fix a 288ms UI hang that occurs when publishing video, caused by synchronous camera initialization blocking the main thread.
📝 Summary
Task.detached
to move blockingRTCCameraVideoCapturer.startCapture()
off the critical path🛠 Implementation
Instruments profiling revealed that
RTCCameraVideoCapturer.startCapture()
(Google's WebRTC code) was blocking the main thread for 288ms with a__psynch_cvwait
during camera initialization.Root cause: The video publishing flow was waiting synchronously for the camera to start before continuing with transceiver setup.
Solution: Wrap the
startVideoCapturingSession()
call in aTask.detached
to allow camera initialization to happen in parallel while the rest of the publish flow continues immediately.This approach ensures the UI remains responsive while the camera hardware initializes in the background.
🎨 Showcase
🧪 Manual Testing Notes
☑️ Contributor Checklist