OpenSwiftUI evaluates display list one extra time with AttributeGraph

[Kyle-Ye]

Summary

With the AttributeGraph backend, OpenSwiftUI reaches the correct final display-list state, but it appears to evaluate the same minimal view one extra time compared with SwiftUI.

This is reproducible on both macOS and iOS Simulator.

Minimal repro

Use the Example app with this content view:

struct ContentView: View {
    var body: some View {
        Color.red
            .frame(width: 50, height: 50)
    }
}

Compare the Example app in OpenSwiftUI mode against SwiftUI mode.

Expected behavior

OpenSwiftUI should avoid the extra initial display-list evaluation when SwiftUI can produce the correctly placed item directly.

Actual behavior

OpenSwiftUI + AttributeGraph first evaluates the red view at (-25, -25), then evaluates it again at the correct centered frame. SwiftUI + AttributeGraph evaluates directly to the centered frame.

OpenSwiftUI + AttributeGraph

View 0x000000013b00ec20 at Time(seconds: 0.0):
(display-list
  (item #:identity 1 #:version 2
    (frame (-25.0 -25.0; 50.0 50.0))
    (content-seed 5)
    (color #FF3B30FF)))
View 0x000000013b00ec20 at Time(seconds: 0.0709835000016028):
(display-list
  (item #:identity 1 #:version 6
    (frame (225.0 125.0; 50.0 50.0))
    (content-seed 5)
    (color #FF3B30FF)))

SwiftUI + AttributeGraph

View 0x0000000138085400 at Time(seconds: 0.0):
(display-list
  (item #:identity 1 #:version 20
    (frame (425.0 214.0; 50.0 50.0))
    (content-seed 41)
    (color #FF3B30FF)))

Notes

• This is separate from the Compute backend placement issue: the final OpenSwiftUI + AttributeGraph state is visually correct.
• The issue is the extra evaluation/update before reaching the final centered frame.
• Current local repro was based on main at 0674dc5a.

[Kyle-Ye]

Additional note: the final-state origin difference in the macOS logs should be ignored for this issue.

The posted logs use macOS as the reproduction environment, and OpenSwiftUI and SwiftUI do not currently start from the same default window/content size there. That can shift the final centered origin even when the relevant layout behavior is otherwise comparable.

The signal this issue is tracking is the extra initial evaluation/render pass while the host bounds are still zero-sized, for example the transient (-25.0, -25.0; 50.0, 50.0) frame before the nonzero host size arrives. On iOS Simulator, where the default host sizing should line up more closely, the final origin is expected to match.

[Kyle-Ye]

Closing this for now.

Current retest results:

• On iOS Simulator, OpenSwiftUI with the SwiftUI renderer no longer reproduces the extra initial evaluation; only one display-list render is observed.
• On macOS, the issue is also no longer reproducible in the current setup.

Given that both checked configurations now match the expected single-render behavior, this no longer looks actionable as an open bug.