Recording forces integrated GPU causing severe performance issues on MacBook Pro 2019

[AasishDairelSahayaGrinspan]

Description

While recording, the application forces the use of the integrated GPU instead of the dedicated GPU.

This results in noticeable performance issues on my system, including lag and reduced responsiveness, making the app difficult to use during recording. I expected the application to utilize the dedicated GPU (AMD Radeon Pro 5300M) for better performance, or at least provide an option to select the GPU manually.

---

Reproduction

1. Open the Cap application
2. Start a screen recording
3. Monitor GPU usage using Activity Monitor
4. Observe that the app switches to the integrated GPU
5. Notice performance degradation (lag/unusable recording)

---

Expected Behavior

• The app should use the dedicated GPU for recording
• Or provide an option to manually select the GPU

---

Actual Behavior

• App uses the integrated GPU
• Causes lag and poor performance
• Recording becomes difficult or unusable

---

Additional Context

• Cap version: 0.4.84
• Operating system, version: macOS Tahoe
• Device :
  • MacBook Pro (2019)
  • Intel i7
  • AMD Radeon Pro 5300M (4 GB)

---

Logs / Notes

No logs attached yet, but can provide if needed.

[linear]

CAP-690

[tembo]

This is related to #586 and #1673 which also report high CPU usage and performance issues during recording. A contributor noted in #586 that Cap uses VTEncoder via AVFoundation for hardware-accelerated encoding, but the hardware acceleration may not be engaging properly in some configurations.

Potential root cause:

The Info.plist at apps/desktop/src-tauri/Info.plist does not set NSSupportsAutomaticGraphicsSwitching. On dual-GPU MacBooks, this key controls whether macOS can switch between integrated and discrete GPUs. Without explicit configuration, macOS may default to the integrated GPU for power efficiency even when the app would benefit from the discrete GPU.

Adding this to the plist could help:

<key>NSSupportsAutomaticGraphicsSwitching</key>
<false/>

Setting this to false tells macOS to prefer the discrete GPU. However, this would increase power consumption and heat for all users, including those on single-GPU Macs where it has no effect.

Relevant code areas:

• wgpu adapter selection: crates/rendering/src/lib.rs - already requests PowerPreference::HighPerformance when calling request_adapter, which should signal to use the discrete GPU
• GPU converters: Multiple modules in crates/gpu-converters/src/ also use PowerPreference::HighPerformance
• VideoToolbox encoder: crates/enc-avfoundation/src/mp4.rs - handles hardware-accelerated encoding

The code already requests the high-performance GPU at the wgpu/Metal layer, but the OS-level plist setting may be overriding that preference for the application as a whole.

Diagnostic suggestion:

Logs from ~/Library/Logs/so.cap.desktop/ would help confirm whether the hardware encoder is being used and if there are any fallback warnings. The app's "Upload Logs" feature can capture these automatically.

[m13v]

Classic ScreenCaptureKit + VTCompressionSession dual-GPU cross-surface copy. NSSupportsAutomaticGraphicsSwitching=false pins to dGPU, but you still pay the PCIe cost every frame if SCStream's IOSurface lives on a different GPU than the encoder. Real fix: match SCStreamConfiguration pixelFormat and colorSpace to what VT expects without a conversion (BGRA + Rec709), plus set kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder. On a 2019 MBP with Radeon Pro, forcing iGPU actually ran smoother than dGPU because the integrated H.265 ASIC handles capture fine and you skip the cross-surface copy entirely.

[AasishDairelSahayaGrinspan]

Classic ScreenCaptureKit + VTCompressionSession dual-GPU cross-surface copy. NSSupportsAutomaticGraphicsSwitching=false pins to dGPU, but you still pay the PCIe cost every frame if SCStream's IOSurface lives on a different GPU than the encoder. Real fix: match SCStreamConfiguration pixelFormat and colorSpace to what VT expects without a conversion (BGRA + Rec709), plus set kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideoEncoder. On a 2019 MBP with Radeon Pro, forcing iGPU actually ran smoother than dGPU because the integrated H.265 ASIC handles capture fine and you skip the cross-surface copy entirely.

Playback and scrubbing inside Cap is broken/laggy on MacBook Pro 2019 (iGPU). The recorded file plays perfectly fine in other apps, so the file is fine. The issue is Cap's own preview/playback renderer it appears to be using the iGPU for playback rendering, which causes lag and makes scrubbing unusable. The fix needs to be on the playback side, not just the recording pipeline specifically using AVPlayerLayer or AVSampleBufferDisplayLayer with proper GPU selection instead of rendering video through WebView.