Skip to main content
DH_Affinitiv
DH_Affinitiv
Participant
February 20, 2026

In After Effects 2026, content aware fill will only fill the first frame, the last frame, and then the second frame., then stops

  • February 20, 2026
  • 1 reply
  • 116 views

In After Effects 2026, content aware fill will only fill the first frame, the last frame, and then the second frame. After that it stops and doesn't do anything else. If those frames already have reference images, or otherwise don't need any fill, it does nothing. It doesn't move on to frame 3 if I try to force it. It just stops at frame 2. I can see the progress bar pop up, analyze, and start rendering, and then stop once frame 2 is done. It doesn't matter if it is set to object or edge blend or surface, it just doesn't do anything. But when I take the same shot over to AE 2025, it works just fine! In 2025 I follow the same steps and it has no problem rendering the entire shot.

      1 reply

      DH_Affinitiv
      DH_AffinitivAuthor
      Participant
      February 20, 2026

      Update: Root Cause Found in Background Render Logs

      I took a look at the logs and used Gemini to help me understand them. This is what I found out. First, it complained there was a layer with Drop Shadow on, even though that layer was off. Even after I soloed a layer with no effects on it, it still complained about that. So I removed all the other layers and effects and ran the Content-Aware Fill. Same result but without complaining about the Drop Shadow effect. This time it complained about Mutli-frame rendering. I went ahead and turned off the Multi-frame rendering in the “Memory & CPU...” menu, cleared my cache and purged my memory, quit everything Adobe, restarted AE26, restarted the file, and made sure the multi-frame rendering was still off. And it still failed. But this time… Gemini was able to spot something...

       

      I dug into the internal After Effects logs for this project to find out exactly why the Content-Aware Fill engine is hanging on frame 2. The logs definitively show a major failure in the latest AE 2026 build on Mac OS 26.3 regarding the Metal GPU framework and a resulting background scripting loop.

      1. Ignored UI Preferences & Severe Metal Load Failures Even though my project was explicitly set to Mercury Playback Engine (Software Only) to bypass the GPU, the background renderer ignored the preference and aggressively tried to initialize the Metal framework anyway. It severely struggled to load the basic pixel format converters, taking almost 48 seconds just to load the GPU modules.

      Here are the exact lines from the log proving the excessive Metal load times:

      • <GPUFoundation.LoadModule> <4> Excessive Load time, ModuleName: "PixelFormatConvert_444_YUV_Xu", LoadTimeMs: 5645.3896484375, Framework: "Metal"

      • <GPUFoundation.LoadModule> <4> Excessive Load time, ModuleName: "PixelFormatConvert_444_1Xu", LoadTimeMs: 4164.36767578125, Framework: "Metal"

      • <GPUFoundation> <5> Done loading modules, sec: 47.8885, device: Metal(0)

      2. Scripting/UI Infinite Loop (The Hang) Once the analyzer finishes the first and last frame, it attempts to hand off the sequential rendering (frame 2) to the background engine. Because the background engine is choked on the Metal initialization errors above, the main UI gets stuck in an infinite background scripting loop waiting for a response.

      Here is the exact line that repeats endlessly in the log every 10 seconds (10,000 ticks) until the program is force-quit:

      • <Scripting EvalScriptViaNativeES script:[try { listProject();} catch(e) {app.log('CEPConnector exception:]...

      Summary:

      • Expected Result: Content-Aware Fill processes the sequence sequentially using CPU only (as strictly defined in the project settings).

      • Actual Result: AE 2026 ignores the "Software Only" setting, forces a broken Metal initialization, hangs the render thread on frame 2, and traps the UI in an infinite listProject() loop.

      • Regression: This exact same project file and layer renders flawlessly in After Effects 2025.

      Could an engineer please look into why the Content-Aware Fill background renderer is ignoring the "Software Only" project settings and stalling out the Metal framework in the 26.0 build?

      DH_Affinitiv
      DH_AffinitivAuthor
      Participant
      February 20, 2026

      Update-Cause Found: AE 2026 Crash: Content-Aware Fill + Metal gdeflate memory limit exceeded in 16-bit color

       

      I decided to take a look at the MacOS logs and what is going on with Metal. It appears that it is exceeding limits or overloading in some way, but only when I have the project set to 16-bit colors. Once I reduce the project to 8-bit, the Content-Aware Fill function works perfectly.
      Here’s Gemini’s summary:

       

      Environment:

      • OS: macOS 26.3

      • Hardware: Mac Studio (M1 Ultra / Mac13,2)

      • AE Version: 26.0.0.67

      Issue Summary: When running Content-Aware Fill in a 16-bit project, After Effects 2026 crashes exactly at the start of frame 2. The process successfully handles the initial and final reference frames but instantly terminates when it begins caching the synthesized in-between frames.

      Switching the project color depth to 8-bit completely resolves the issue and allows Content-Aware Fill to complete successfully.

      Log Analysis & Root Cause: The crash is not a standard memory access violation, but an OS-level termination because After Effects exceeds Apple's disk write limits. The macOS Microstackshots diagnostic logs show the application dirtying 2148.67 MB of file-backed memory in a single burst, triggering a write-limit exception.

      The thread stack during the crash points directly to the new GPU-accelerated cache compression pipeline overworking itself with the 16-bit data:

      1. MC_Stuff::PrepAndWrite

      2. BEE_ItemCacheValueData::Write

      3. bee::gdeflate::WriteRawPFWorld

      4. write (System call where the termination occurs)

      Additionally, the AE logs show the Metal framework severely struggling to load higher bit-depth pixel format converters during initialization. Specifically, PixelFormatConvert_444_YUV_Xu takes over 5.6 seconds to load, contributing to a massive ~48-second total load time just for the Metal modules.

      Conclusion: It appears that combining 16-bit color depth with the new Metal-accelerated gdeflate disk caching pipeline overwhelms the I/O limits on Apple Silicon when Content-Aware Fill tries to aggressively cache synthesized frames. Bypassing 16-bit color bypasses the bottleneck.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices