Hello everybody!

(This post was co-authored by Tim Kurkoski (After Effects Product Owner), Andrew Cheyne (After Effects Engineering Manager), and Victoria Nece (After Effects Product Manager).)

This thread has been sitting here for quite a while without a response. To start, we want to apologize for that. We haven’t been ignoring you or your feedback – this is just a particularly complex topic. That said, it’s time for us to check in with you, clarify a few things, and give you an idea of what we’re looking at for the future of After Effects, especially when it comes to performance.

To start, we fully understand that you want After Effects to be as fast as it can be – utilizing your computer’s hardware resources to render as fast as possible. Over the last several years, we have been working on the performance of After Effects constantly. Sometimes those performance gains are obvious, like GPU rendering or improving an individual effect’s use of the CPU. Sometimes it’s less obvious, like making expressions evaluate faster via a modern JavaScript engine.

Before jumping into the specific request here (multi-threading AE), we should talk about how the AE team looks at performance in general. There are three areas:

• Rendering Performance: How fast can AE get pixels onto your screen?

• Interactive Performance: How fast does the UI respond to your actions?

• Workflow Performance: How fast can you complete a task in AE?

All three are important. All three impact how quickly you can make creative decisions and get your work done. This request and this discussion are focused on the first area, rendering, so we will focus on that, however we don’t want to lose sight of the bigger picture.

Rendering Performance

What have as the AE Team been doing? When we set out to tackle rendering performance, we looked at the potential improvement offered by different technical paths. And we set a high bar: we didn’t want to just have an incremental speed increase. We wanted a major leap forward in rendering power.

The obvious technology that would enable us to achieve that goal was leveraging the GPU. Because GPU processing power has leapfrogged the CPU — and is explicitly designed to handle this type of processing — the decision was made to invest in getting AE’s core rendering pipeline running on the GPU.

This is not a small task, and we’re not done yet. The most visible result of this effort has been the porting of individual effects to the GPU – more than 40 so far. Less visible is the work we’ve done getting the rest of the After Effects rendering pipeline on the GPU, such as layer transforms and motion blur or debayering RED raw R3D footage.

We still have further to go, as the real power of the GPU is unlocked when you don’t have to send a frame back and forth between CPU and GPU for different stages of rendering. As more links of the GPU chain come online, you can expect further rendering performance gains.

Multi-Threading

We do know what you’re thinking at this point. You want to know what we’re doing about multi-threading.

We all recognize that After Effects would benefit from additional general-purpose multi-threaded rendering. And while we can’t get into specifics here or make any promises about our future roadmap (that’s all confidential when you’re a publicly traded company), we are actively working on multi-threaded CPU rendering.

Ultimately, when it comes to achieving the best rendering speeds possible for AE, we know we’ll need a combination of GPU and CPU processing that maxes out all the resources on your machine.

We recently partnered with the folks at School of Motion and they did a fantastic video on how to get a more optimized system for After Effects: https://www.schoolofmotion.com/tutorials/after-effects-computer

Please keep posting and letting us know what you think. We’ll continue to watch this thread (and all the others on UserVoice). And we appreciate your patience with our response to this post.

Thank you for filing this bug report. We are investigating a fix for this problem for a future update to After Effects.

The conditions under which this problem occurs had eluded us for a long time. Only recently were we able to observe the combination of factors that are required to cause this problem:
- This happens on macOS only, not on Windows.
- The After Effects UI is spread over multiple monitors.
- The Render Queue panel is in a floating window outside of the main After Effects application window.
- That floating window is on a different monitor than the main application window.
- The Render Queue panel is docked in this floating window with either the Timeline or Composition panels.
- When you start the render queue, a modal dialog (a progress dialog or a warning dialog) appears over the main application window.

When all of the above conditions are met and the modal dialog closes, the Timeline or Composition panels (whichever is docked with the Render Queue panel) will come forward and hide the Render Queue panel.

This problem appears to have existed in After Effects for a very long time, but began to occur more frequently in After Effects 13.6 and later, when behavior was added to auto-save the project when the render queue starts. The auto-save process displays a modal progress dialog, which can invoke the problem, as per above.

But the auto-save process dialog is not the only dialog that can cause this problem. Other warnings such as color depth mismatch, missing footage, or existing file names could also cause this to occur.

There are a few ways you can avoid this problem:
- Dock the Render Queue panel in the main application window, not a floating window.
- Do not dock the Render Queue in the same panel group as the Timeline or Composition panels, if they are in a floating window on a secondary monitor. (Or the Layer panel, although this panel only causes the problem if a layer of the rendering composition is open.)
- In Preferences > Auto-Save, disable “Save when starting render queue”. However, this will not prevent the problem from occurring if other warning dialogs occur.
- Sometimes, but not always, the problem will not happen if you drag the modal dialog, before it closes, from the primary monitor to the secondary monitor where the Render Queue dialog is. This is feasible for warning dialogs when it is waiting for your response, but progress dialogs like the auto-save dialog may not be visible long enough for you to do this.

I hope this helps clarify the situation and prevent some pain until we can provide a fix for the problem. We’ve been hearing reports of the problem for quite some time, but as I noted above, we weren’t able to reproduce the issue until we observed the full set of conditions that are required to cause it to happen. Now that we know these conditions, we are investigating a fix for a future update.

Thank you for sharing the project file. I was able to reproduce the problem, both with your project and by replicating the conditions of the bug from scratch.

This is a bug which has existed in the Mesh Warp effect for a long time. At this time we do not plan to fix it, because the conditions of the bug are uncommon and easy to work around. But we will leave this bug in “Under Review” state to allow people to continue to vote on it. If this problem is more common that we assume, we can raise the priority and fix this in a future update.

The problem is a combination of a high-resolution layer and moving the mesh warp points a great distance outside of the bounds of the layer.

In this case, your layer is greater than 8000×5000 pixels, though scaled down to 10%, and one of the mesh points extends quite some distance beyond the layer. Bringing that mesh point in, or using a smaller layer, will avoid the problem.

The composition resolution does have a factor in the problem; when set to Half or lower, the render resolution of the layer changes, which avoids the problem. But at Full resolution, or rendering via the render queue at full resolution, the bad condition is encountered.