Troubleshooting: Loom “Frame Rate Drop” during Software Demos

A frame rate drop during a Loom software demo means the recording software is discarding video frames in real time, making animations, cursor tracking, and screen transitions look choppy or jittery. This bottleneck happens when your graphics hardware or CPU cannot simultaneously render the software being demonstrated and encode Loom’s video capture stream.

Fast Fix

Open Loom’s Preferences, drop your recording resolution from 4K or 1440p down to 1080p at 30 fps, and switch the capture mode from “Entire Screen” to “Window.” If you use an external monitor or a gaming display, disable Variable Refresh Rate (G-Sync, FreeSync, or Apple ProMotion) and lock the monitor refresh rate to 60Hz to prevent encoder timing mismatches.

---

Diagnostic Snapshot

Parameter	Operational Detail
Failure Layer	Hardware encoder (NVENC/QuickSync/VideoToolbox) saturation or GPU contention
Common Environments	High-DPI screens (4K/Retina), 120Hz+ gaming monitors, GPU-heavy apps (Figma, CAD, IDEs)
Impact	Jerky video playback, missed cursor movements, desynced audio/video streams
Admin Access Required	No (handled via local OS display and Loom settings)

---

Diagnostic Path: Isolating the Encoder Bottleneck

To locate what is choking your frame rate, isolate the capture surface from the underlying software demo:

Framerate drops during recording
       │
       ├──> Does the stutter happen only when running a specific demo app (e.g., Figma, Unreal, CAD)?
       │      └── YES: GPU contention. The demo app is starving Loom's hardware encoder.
       │
       ├──> Does the stutter happen on all apps when recording a 120Hz/144Hz or 4K screen?
       │      └── YES: Display timing mismatch or pixel bandwidth saturation.
       │
       └──> Does the video look smooth on screen, but plays back choppy on Loom.com?
              └── YES: Cloud rendering or local hardware encoding fallback failure.

1. Identify GPU Resource Contention: Loom relies on your computer’s GPU hardware encoder (such as Apple Silicon’s Media Engine, Nvidia NVENC, or Intel QuickSync). If the application you are demonstrating—like Figma with heavy canvases, 3D engines, or large web apps in Chrome—claims 90% or more of GPU compute, the hardware encoder misses its target frame delivery windows.
2. Detect Variable Refresh Rate (VRR) Clashes: High-refresh displays that dynamically vary their refresh rates (e.g., G-Sync, FreeSync, ProMotion) force frame intervals to fluctuate. Loom’s video pipeline expects steady 30 or 60 fps intervals; irregular frame pacing results in dropped frames.
3. Differentiate Dropped Capture Frames from Dropped Playback Frames: If your completed video is choppy in the browser player, test local playback by downloading the raw .mp4. If the downloaded file is smooth, your issue is browser hardware acceleration during playback, not capture failure. For broader capture overhead on macOS, consult Fix: Loom “Canvas” Drawing tools lagging on macOS.

---

Step-by-Step Resolution

Step 1: Cap Display Refresh Rate to 60Hz

Running your monitor at 120Hz, 144Hz, or 240Hz forces Loom to downsample frames in real time, which burns CPU cycles and causes frame-pacing stutter.

• On Windows 11:
  1. Open Settings > System > Display > Advanced display.
  2. Under Choose a refresh rate, change dynamic or high settings to 60.00 Hz.
  3. If using an Nvidia GPU, open Nvidia Control Panel, go to Set up G-SYNC, and uncheck Enable G-SYNC, G-SYNC Compatible.
• On macOS:
  1. Open System Settings > Displays.
  2. Select your internal display or connected external monitor.
  3. Under the Refresh Rate menu, select 60 Hertz instead of ProMotion or higher variable rates.

Step 2: Change Loom Capture Target to “Window”

Capturing an entire 4K monitor requires your computer to process roughly 8.3 million pixels per frame. Capturing a single application window cuts that pixel count significantly:

1. Click the Loom icon to open the recorder panel.
2. Under the capture options, select Window instead of Full Screen.
3. Select only the application you are demonstrating. This bypasses the overhead of rendering background desktop processes, system notifications, and wallpaper compositing.

Full Display Capture (4K at 60Hz): ~500M pixels/sec ──► High Encoder Saturation (Drops Frames)
                                                                 │
Window-Only Capture (1080p at 30Hz): ~62M pixels/sec ──► Low Encoder Load (Zero Dropped Frames)

Step 3: Configure Hardware Acceleration and Encoder Fallback

If your GPU driver fails to allocate memory buffers for Loom while running heavy software, Loom drops frames as it struggles to switch between GPU and CPU processing.

• Open Loom’s settings and verify whether hardware acceleration is behaving properly. If your system shifts erratically between native hardware chips and software encoding, review Troubleshooting: Loom “Hardware Encoding” vs “Software Fallback” to configure consistent encoder behavior.
• If demonstrating browser-based apps, disable background graphics strain in Chrome: go to chrome://settings/system and toggle off Continue running background apps when Google Chrome is closed.

Step 4: Adjust Resolution and Scaling

If Loom recordings consistently fail to match your screen resolution and downscale awkwardly, review Fix: Loom “Resolution Mismatch” (1080p recording showing as 720p). Running display scaling settings like “More Space” on macOS forces the operating system to render a massive virtual desktop canvas before scaling it back down, creating heavy capture lag during app demos.

---

Verification and Advanced Monitoring

After applying the fixes, verify that your computer has sufficient encoding headroom:

1. Open Task Manager (Windows) or Activity Monitor (macOS).
2. Start a test software demo recording in Loom while actively moving windows and navigating menus.
3. Check the GPU Engine column in Windows Task Manager:
   • Video Encode engine should remain below 80% utilization.
   • 3D / Compute engine should not peg at 100%.
4. On macOS, verify that WindowServer remains below 40% CPU usage during active window movement. If utilization stays under these thresholds, your demos will record with consistent frame pacing and smooth motion.