https://livekit.io logo
Join Slack
Powered by
Using LiveKitRoom in flutter rebuild the entire wi...
# ask-ai
b
Using LiveKitRoom in flutter rebuild the entire widgets and heats up the device. is this normal?
t
Thanks for reaching out, Ahmed. I'm an AI assistant and I'm here to help. Give me a moment while I research this topic.
You're right to be concerned — rebuilding the entire widget tree with 
LiveKitRoom
and significant device heating is not normal. Below are likely causes and concise actions you can take to diagnose and fix it. What I'm responding to: your 
LiveKitRoom
rebuilds the whole UI and the device heats up. Likely causes • Frequent or broad state updates (too many calls to 
setState
or global rebuilds). • Video rendering for many or background participants (video decoding is CPU/GPU intensive). • Subscribing to all tracks automatically in large rooms (
autoSubscribe: true
) causing heavy bandwidth/processing. • Excessive or non-disposed event/listener callbacks (e.g., 
EventsListener
) causing repeated work. Quick actionable steps 1. Limit rebuild scope ◦ Only wrap the parts that change (participant list, single video tile) in stateful widgets and call 
setState
locally. ◦ Use Provider, Riverpod, or another scoped state manager so changes don’t rebuild the entire tree. 1. Render video only when visible ◦ Use 
VideoTrackRenderer
or the video widget only for active/visible participants. ◦ Stop or pause rendering for background/hidden participants. 1. Reduce subscriptions and bandwidth ◦ Consider 
autoSubscribe: false
and subscribe to tracks selectively for visible participants. 1. Manage listeners ◦ Add and remove 
EventsListener
and participant listeners carefully; dispose them when no longer needed. 1. Profile resource usage ◦ Test on a device while profiling CPU/GPU and memory to see which operations spike during rebuilds. If you want, share a minimal code snippet showing how you use 
LiveKitRoom
(especially state updates, listeners, and video widgets). I can point out exact spots to change. Sources: Handling events | LiveKit docs | client-sdk-android | livekit/livekit_composite | DeepWiki | Subscribing to tracks | LiveKit docs | Optimizing Video Calls for Low-Powered Devices in LiveKit (JS SDK ≥ v2.14.0...
b
Can I wrap some different widgets with LiveKitRoom in same page ?
t
You're asking whether you can wrap different widgets with 
LiveKitRoom
on the same page — yes. Key points and best practice: • You can place multiple child widgets inside a single 
LiveKitRoom
(video tiles, controls, participant list, etc.). All children can access the room via 
Room.of(context)
. • Prefer a single 
LiveKitRoom
at the top of the meeting screen and make UI components its descendants to avoid multiple full connections. • Avoid creating multiple 
LiveKitRoom
instances on the same page unless you explicitly need multiple separate room connections (this creates separate network/CPU overhead). • Keep video rendering limited to visible/active participants and scope state updates so individual child widgets re-build instead of the entire tree. If you’d like, share a small snippet of your widget tree and I’ll point out where to place 
LiveKitRoom
and how to minimize rebuilds. Sources: Flutter quickstart | LiveKit docs | Handling events | LiveKit docs | Connecting to LiveKit | LiveKit docs | Stream music over WebRTC using React and WebAudio
b
yes
t
Thanks — to give precise guidance, could you paste a small code snippet of your current widget tree showing where you place 
LiveKitRoom
and the child widgets you want to wrap? Useful details to include: • The 
LiveKitRoom
usage (props like 
token
, 
autoSubscribe
) • How you handle state updates (where you call 
setState
, providers, listeners) • How you render video (which widgets use 
VideoTrackRenderer
or video views) With that I’ll point out exact changes to minimize rebuilds and CPU/GPU load.
b
<LiveKitRoom><MediaPlayer><ChatList><UsersList>
t
Good — with that structure you can and should keep a single 
LiveKitRoom
as the parent. Quick, concrete recommendations to avoid full-tree rebuilds and reduce CPU/GPU load: 1. Single-room structure • Use one 
LiveKitRoom
at the top (wrap the whole meeting page). All children (
MediaPlayer
, 
ChatList
, 
UsersList
) should be descendants so they access the room via 
Room.of(context)
. 1. Limit rebuild scope • Make each child its own StatefulWidget (or use Provider/Riverpod) so state changes inside 
ChatList
or 
UsersList
call 
setState
only for that widget. • Avoid calling 
setState
in the parent that contains 
LiveKitRoom
for child-specific updates. 1. Video rendering • Only render video in 
MediaPlayer
for visible/active participants using 
VideoTrackRenderer
or the provided video widget. • Pause/stop rendering for hidden participants (e.g., when scrolled offscreen or in another tab). 1. Subscriptions & bandwidth • Consider 
autoSubscribe: false
if you have many participants and subscribe only to tracks shown in 
MediaPlayer
. 1. Listeners & disposal • Attach room/participant listeners inside the specific child widgets and dispose them in 
dispose()
to prevent repeated callbacks and leaks. 1. Profiling • Profile on a target device to see CPU and GPU hotspots; if a single widget causes spikes, focus optimization there. If you want, paste the full widget code for 
MediaPlayer
, 
ChatList
, and 
UsersList
(or the parts where you call 
setState
/ attach listeners) and I’ll mark exactly where to refactor.
2 Views
Open in Slack
PreviousNext
Powered by