Add video renderer pool prewarming API#839
Add video renderer pool prewarming API#839sampepose wants to merge 1 commit intoGetStream:developfrom
Conversation
- Add VideoRendererConfiguration public API for prewarming video renderers - Add internal configure method to VideoRendererPool for capacity management - Fix thread safety issue in ReusePool initialization - Eliminates 150-200ms UI hangs when video views are first created
| /// Used for prewarming to add elements beyond initial capacity. | ||
| /// | ||
| /// - Parameter element: The pre-created element to add to the pool. | ||
| func addToAvailable(_ element: Element) { |
There was a problem hiding this comment.
This method defies the Pool's purpose. The pool is responsible for creating its elements on demand.
| /// | ||
| /// - Parameter initialCapacity: The number of video renderers to pre-create. | ||
| @MainActor | ||
| static func configure(initialCapacity: Int) async { |
There was a problem hiding this comment.
This is what is happening on the reusePool initialisation. I don't see a reason for this method.
There was a problem hiding this comment.
The default value is 0: https://github.com/GetStream/stream-video-swift/blob/develop/Sources/StreamVideoSwiftUI/Utils/VideoRendererPool/VideoRendererPool.swift#L20
This entire PR could be removed if that default value is changed, but I didn't want to change the default behavior for all users unexpectedly. So this PR is just a way to expose that number.
| /// // Then later initialize StreamVideo as usual | ||
| /// let streamVideo = StreamVideo(apiKey: apiKey, user: user, token: token) | ||
| /// ``` | ||
| public static func prewarm(count: Int = 2) { |
There was a problem hiding this comment.
This method looks unnecessary. Can you elaborate more on why this is needed and why the existing warm up on init isn't sufficient?
| let element = factory() | ||
| available.append(element) | ||
| // Initialize the pool with a set number of elements (thread-safe) | ||
| queue.sync { |
There was a problem hiding this comment.
Hmm i'm not sure about this one. Even without the sync, there aren't multiple threads accessing the initialiser at the same (if they were they would be creating different instances).
2 participants
🎯 Goal
Eliminate UI blocking when video renderers are first created during video calls, improving user experience by preventing 150-200ms hangs.
📝 Summary
VideoRendererConfiguration.prewarm()public API for creating video renderers proactivelyReusePoolinitialization🛠 Implementation
New Public API:
Key Implementation Details:
prewarm(count:)method that can be called from any threadawait Task.yield()between each creation to prevent blocking the UI thread for extended periodsReusePool.init()where initial elements were created outside of the thread-safequeue.syncblockaddToAvailable()method toReusePoolfor adding pre-created elements beyond initial capacityTechnical Approach:
🧪 Manual Testing Notes
VideoRendererConfiguration.prewarm(count: 2)early in app lifecycle, then create video call - should see immediate video appearance☑️ Contributor Checklist