Performance-problems with Screenflow 10 (lagging etc.)


I encounter performance-problems, especially in handling the timeline.


  • I drag the handle-bar, it moves with 0.5-1 second delay
  • I zoom in or zoom out, also big delays. When I zoom with alt + mousewheel the changing happens in 0.5-second-steps, so I can watch him zooming to the next level, then the next, then the next.
  • Clicking somewhere (timeline, or object on the recording) and dragging an object around -> lag as stated above.

Sometimes the lag is so big that the macOS-rainbow-spinning-wheel appears.

With smaller videos up to 7, 8 minutes this does not happen noticeable. But now I am working with bigger files (4 recordings: 4k-cam, 4k-screen, hd-screen, audio;  about 50 minutes capturing time; filesize of the packed document *.screenflow is between 6-10 GB) and Screenflow is almost unusable, esp. when I make a lot of cuts, annotations etc.

Please note that the behavior not only appears while the audio-waveform is being rebuilt (as you can see next to the time-display in a percentage-progress-circle).



  • Mac Pro 2019, 3,5 GHz 8-Core Intel Xeon W, AMD Radeon Pro 580X 8GB, 96 GB RAM
  • Samsung X5  connected via Thunderbolt (blazing fast, faster than my internal SSD).

Please note that I am not low on ressources; when I look at the activity-monitor I see Screenflow using about <1GB RAM (about 70GB RAM free on the whole OS), CPU-% is far from full workload.

Program Settings

Screenflow 10.0.3 (most recent version) with the following settings:

  1. Settings->Timeline->Miniatur-Cache: Limit Size to 800MB
  2. Proxy: automatically [changing to "always" makes no difference, but I tried those changes only when the recording was already done]
  3. Proxy: Limit Proxy-Cache to 60GB
  4. Proxy: Create Proxys with half original resolution
  5. Proxy-Cache: X5 -> /proxy/ [changing the volume makes no noticable difference]
  6. Advanced: Screenrecording compression: adaptive
  7. Advanced: Standard file format: packed document [changing this makes no difference]
  8. Advanced: Recording volume: X5 -> /scratch/ [changing the volume makes no noticable difference]

Also changing the location of the .screenflow-file (e.g. to another volume) doesn't seem to make any noticable difference.

Tried Solutions

  • As posted above I tried to change scratch-volumes or proxy-settings.
  • When I uncheck Appearance -> Show Audio Wave Form, it sometimes gets better, but not for long.
  • I read in this forum somewhere that changing the setting from "packed document" to "document with 1 file" (or vice versa, don't remember) solved the problem, but for me it didn't (see above). I tried this change only with the recording already made.
  • Deleted user/Library/Caches/net.telestream.screenflow10
  • Restarting the program doesn't help.
  • Restarting the whole machine seems to help, but not for long.
  • Certainly I make sure that there are no other big programs are running while I use Screenflow.
  • Read somewhere that unchecking the "remove background-noise"-setting for the audio-tracks is helpful, but this is unchecked on all my audio-tracks.

So please …

I would appreciate any help very much, even if just tips how to boost performance, as I cannot work this way. Thanks in advance!

2replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Sorry you're having performance issub tut It's difficult to make system-specific recommendations especially since performance is subjective. Also document content may be a factor. So it's only possible to make the most general recommendations.

    Proxy encoding itself takes time and waiting until that's done will result in faster performance. If you can't wait then one shouldn't use proxies. Avoid importing HEVC files or files with very long GOP (few keyframes). Those are examples of files that should be proxied or otherwise converted before import.
    Turning off Thumbnails and Waveform entirely can help performance.
    Scratch Disk to Startup Volume may or may not be faster than using an external drive keeping in mind it's not just the drive speed but the throughput going to the external drive may be a factor. 
    Yes some filters (audio and video) may slow things down but the best I can say is "it depends" since there are variables with each project.

  • Implicitely you gave me the solution: I just had to disable thumbnails (which I did not try before). The program is running smooth as it used to be. I don't need thumbnails for a efficient workflow.

    It seems that creating thumbnails is an extremely performance-intensive task (esp. as I am working on a rather big machine), so probably other people have the same issues with this. Maybe the developers should have a look on this.

    Anyhow - you saved my life again. Thanks for your help, Craig!!!

Like Follow
  • Status Answered
  • 2 mths agoLast active
  • 2Replies
  • 10Views
  • 2 Following