Skip to main content
Jonathan378309557kry
Participant
August 30, 2026

Possible Expression Engine Bug: Resolver State Depends on Dependency Traversal

  • August 30, 2026
  • 3 replies
  • 142 views

Hi,

I've been investigating a reproducible issue involving transform expressions and property[index].

What initially looked like a simple circular-dependency edge case now appears to be something more fundamental: the resolved state of the graph seems to depend on which dependency branch is traversed.

Adobe After Effects 25.6.4
Windows 11

Setup

Layer: property index

Anchor Point:

thisLayer.scale[0];
thisLayer.rotation[0];
thisLayer.opacity[0];
thisLayer.position[0];
thisLayer.anchorPoint[0];

[11,22]

Position:

thisLayer.anchorPoint

Scale:

thisLayer.anchorPoint

Rotation:

thisLayer.anchorPoint[0]

Opacity:

thisLayer.anchorPoint[0]

Observation

Depending on layer arrangement and evaluation order, the graph can expose a mixture of expression values and pre-expression values.

For example, the Transform panel may show:

Anchor Point = 11,22
Position     = 11,22
Scale        = 40,80
Rotation     = 40
Opacity      = 40

while external reads may report:

Anchor Point = 11,22
Position     = 40,80
Scale        = 40,80
Rotation     = 40
Opacity      = 11

In other words, different access paths appear to observe different states of the same dependency graph.

Stronger Repro

The most surprising result is that the final expression output does not seem to matter.

For example:

if (random() < .5)
    thisLayer.scale[0];
else
    thisLayer.position[1];

0;

The expression always returns:

0

However, simply touching different dependency branches can change the resolved state observed elsewhere in the graph.

The referenced values are discarded and never contribute to the final output.

Additional Test

This expression:

switch (timeToFrames(time) % 4){
    case 0: throw(thisLayer.scale[0]);
    case 1: throw(thisLayer.position[1]);
    case 2: throw(thisLayer.rotation);
    case 3: throw(thisLayer.opacity);
}

produces different outputs depending on which dependency branch is selected.

This suggests that the resolver outcome is affected by traversal path rather than only by the graph itself.

Why This Seems Wrong

I would expect:

Result = f(graph)

Instead, the observed behavior looks more like:

Result = f(graph, traversal path)

where simply visiting a different dependency branch can change the state produced by the resolver.

The most surprising part is that these branch references do not need to contribute to the final returned value.

Core Question

Is dependency traversal intentionally allowed to influence cycle resolution for transform graphs involving property[index]?

Or does this indicate a resolver bug where different traversal paths can lead to different graph states, causing properties to alternate between expression values and pre-expression values?

3 replies

Jonathan378309557kryAuthor
Participant
September 1, 2026

I just found out, that text changes in Premiere randomly between pre expression and expression value with just: 

sourceRectAtTime();
style.setFont("ArialMT");

Attached a project with one minimal example for scale flicker and one for text flicker.

Jonathan378309557kryAuthor
Participant
August 30, 2026

I found a related Premiere Pro behavior that may point to the same underlying issue.

I was able to reduce a flickering MOGRT to the following minimal example.

Anchor Point:

thisLayer.scale * 1;
[0,0]

Scale:

thisLayer.anchorPoint

The Scale property's static value is:

[80,80]

In After Effects, the result is stable and deterministic.

Anchor Point evaluates to:

[0,0]

Scale evaluates to:

[80,80]

No flicker occurs.

However, the exported MOGRT flickers in Premiere Pro.

The interesting part is that the values are not random. The flicker occurs between exactly two states:

[80,80]

and

[0,0]

These correspond exactly to the property's pre-expression value and expression value.

So this does not appear to be a case where Premiere is producing arbitrary values. Instead, it appears to alternate between the pre-expression and expression states of the same dependency.

The setup contains no animation, no randomness, no time-dependent functions, no changing inputs, and no external layer references, so there is nothing in the project itself that should vary from frame to frame.

This seems related to the observations in the original post because the result depends on which state of the dependency graph is returned. In AE the graph resolves consistently to the pre-expression state. In Premiere the renderer appears to alternate between the pre-expression and expression states, resulting in visible flicker.

Has anyone else observed Premiere switching between pre-expression and expression values in circular dependencies, even when AE evaluates the same setup deterministically?

Jonathan378309557kryAuthor
Participant
August 30, 2026

Update

I originally believed that property[index] access was required to reproduce the issue.

Further testing suggests that this is not the case.

The same behavior can be triggered by simple property references that force dependency traversal without using indexed access.

For example:

thisLayer.anchorPoint * 1;
thisLayer.position * 1;
thisLayer.scale * 1;
thisLayer.rotation * 1;
thisLayer.opacity * 1;

and:

if (random() < .5)
    thisLayer.scale * 1;
else
    thisLayer.position * 1;

0;

can still alter the resolved state of the graph, even though the referenced values do not contribute to the final result.

The expression above always evaluates to:

0

yet simply traversing different dependency branches appears sufficient to change the state observed elsewhere in the graph.

This suggests that the underlying issue is not indexed component access itself. Instead, it appears that traversing different dependency branches can influence the resolver's chosen state.

At this point, the issue seems more accurately described as:

The resolver outcome depends on dependency traversal rather than being determined solely by the dependency graph itself.

In other words, merely touching different branches of the same cyclic graph can lead to different resolved states, even when those branches have no effect on the expression's final output.

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