Camtasia 9: Are you going to utilize the GPU for rendering or not?

  • 2
  • Problem
  • Updated 5 months ago
  • (Edited)
Like the ESPN NFL segment...."C'MON, MAN!"

What is the deal with GPU acceleration? I've been waiting on Camtasia to finally make use of the beast I have in my machine (GTX 1070). In CS 8, there is supposed to be some GPU utilization for rendering, but it is rather weak in it's implementation as GPU-Z shows there is only 12-24% GPU load when rendering.

In Camtasia 9, there is no option for GPU ENcoding in the Preferences panel, whatsoever. C'MON MAN! Let us get the most out of our hardware, rather than have to go on a lunch break waiting for our render to finish.
Photo of dnashj33


  • 68 Posts
  • 13 Reply Likes
  • frustrated

Posted 3 years ago

  • 2
Photo of Dave O'Rourke

Dave O'Rourke, Senior Software Engineer

  • 1446 Posts
  • 420 Reply Likes
Official Response
Pushing frames to the GPU is fast.  Pulling frames back off the GPU is slow.  For that reason, Camtasia 9 uses the GPU (by default) for preview on the canvas, and the CPU for rendering during production to file.  If we used the GPU for rendering during production, you'd see a higher % utilization on the GPU, but it would take longer to complete the render.

But even this is an over-simplification.  You have to look at the whole render pipeline to determine where the bottleneck is.  This analysis is project and machine dependent.  It's the slowest link in the pipeline that determines the max render throughput.  For production, that's usually the encoder, which is CPU bound right now.  But it can also be disk read/write times if your disk is slow, or if you've sourced files from a network drive or thumb drive (don't do this, please).  Some effects are expensive, and though the GPU is usually faster, there are some effects that are rendered faster on the CPU.  The dimensions of the source files and canvas matter too, with smaller dimensions able to render faster.  Scaling of images and video is done 30x for each sec of video on the timeline, so that needs to be fast.  Decoding 60fps sources can be slow.  Then there's the number of stacked tracks at a given time.  Etc.  So it's complicated.

We continue to look for ways to leverage the hardware to the fullest extent, and we do try not to be worse than in previous versions, whenever possible.  But it's a complicated optimization problem, with many variables, across many different hardware systems.  If you're seeing lags in performance, we do want to know, as there may be something we can tweak to eek out some more performance in future versions.