Maniphest T67736

Delay in Compositor on frame change
Closed, Duplicate

Assigned To
None
Authored By
Sebastian Koenig (sebastian_k)
Jul 26 2019, 3:07 PM
Tags
  • BF Blender
Subscribers
Sebastian Koenig (sebastian_k)
Sergey Sharybin (sergey)

Description

System Information
Operating system: Linux-4.4.0-151-generic-x86_64-with-debian-stretch-sid 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 430.26

Blender Version
Broken: version: 2.80 (sub 75), branch: master, commit date: 2019-07-26 08:15, hash: rB250995d67b77
Worked: 2.79

Short description of error
In Blender 2.79 I could cycles through an image sequence with realtime feedback in the compositor, now there is a significant delay before the new image is displayed.

Exact steps for others to reproduce the error
Open the archive below. There are 20 frames from Tears of Steel and 2 blendfiles, one for 2.79, one for 2.80.
Open the one for 2.79 and cycles through the frames with arrow keys. The content of the backdrop changes almost immediately.
Now open the file for 2.80 and cycle through the frames: You'll notice a significant lag. It's as if the compositor is waiting for something until it does something.

Event Timeline

Sebastian Koenig (sebastian_k) created this task.Jul 26 2019, 3:07 PM
Sebastian Koenig (sebastian_k) added a subscriber: Sergey Sharybin (sergey).Jul 26 2019, 3:17 PM

Actually, it seems the problem only exists when using a MovieClip as input. When trying the same clip as Image Sequence, performance is back to normal, with realtime feedback.
Smells like teen depsgraph!
So maybe something for you, @Sergey Sharybin (sergey)? :)

Sergey Sharybin (sergey) added a comment.Jul 26 2019, 4:16 PM

This is not dependency graph.

Weird it sounds, this is same root of the issue as T66872: compositor will use own caching system for the movie clip, and that system is created and tossed away on every re-compo. This is also why old-style color management tagging is not properly refreshed in T66872.