Presentation open path: open-sheet content re-Evaluates on every presenter recomposition, a guaranteed empty first frame, a preference settle pass, and a new Dialog window per presentation

Environment

• skip 1.9.4, skip-fuse-ui 1.17.2, skip-ui 1.57.0
• Fuse app; Kotlin 2.3.0, compileSdk 35, Material3 ModalBottomSheet

Summary

Opening and holding a sheet/alert/cover pays five separable framework costs that together make presentations feel noticeably less fluid than iOS running the identical SwiftUI code. Filing as one issue because they share the Presentation.swift open path — but each is independently fixable, and any subset helps.

a) Open sheet content re-Evaluates on every presenter recomposition

.sheet/.alert/.fullScreenCover install a PresentationModifier whose action runs inline in the presenter's render scope (View/ModifiedContent.swift:69–71 action?(context); Layout/Presentation.swift:1286–1290). While presented, every presenter recomposition re-evaluates the sheet's entire content graph:

// Layout/Presentation.swift:100–103
if isPresentedValue || sheetState.isVisible {
    ...
    let contentRenderables = ComposeBuilder.from(content).Evaluate(context: context,
        options: EvaluateOptions(isKeepNonModified: true).value)

A busy presenter (timers, observable ticks, geometry writes) rebuilds the open sheet's full Renderable graph each frame even though the sheet draws in a separate window.

Suggested fix: cache contentRenderables keyed on content identity (remember/derivedStateOf), or move the Evaluate inside the ModalBottomSheet scope; the up-front evaluation is only needed to harvest modifiers — memoize that harvest.

b) Guaranteed empty first frame in PresentationRoot

Bounds seed to Rect.Zero, real bounds arrive via a post-layout callback, and content is gated on non-Zero — so the first composition of every presentation renders nothing:

// Containers/PresentationRoot.swift:40, 56–60
let presentationBounds = remember { mutableStateOf(Rect.Zero) }
...
.onGloballyPositionedInWindow { presentationBounds.value = $0 }
...
guard presentationBounds.value != Rect.Zero else { return }

Suggested fix: read insets without the layout round-trip (WindowInsets.safeDrawing composition locals) so the first frame renders content.

c) Presentation preferences need an extra composition to settle

Detents/drag-indicator propagate as preferences collected inside the sheet subtree, visible only on the next composition — frame 1 uses defaults, frame 2 corrects (detent collected at Presentation.swift:133–135, consumed for inset at :147–151). The code already documents the limitation and hand-hoists one value out of the preference system because of it:

// Layout/Presentation.swift:116–119
// Implementing backDismissDisabled as a preference doesn't work because preferences require an
// extra composition and only the first composition of `ModalBottomSheetProperties` is taken into
// account. So we require the modifier directly on the content view
let backDismissDisabled = isBackDismissDisabled(on: contentRenderables)

Suggested fix: harvest all presentation preferences the same way — up front from the already-evaluated contentRenderables — and instantiate ModalBottomSheet with final geometry, removing the settle-frame jump.

d) Measured-before-animate + e) a fresh Dialog window per open

Sheets go through stock ModalBottomSheet with no height hint (Presentation.swift:98, :125), so heavy content is measured before the slide starts; and each presentation is hosted in a brand-new Dialog window, with system-bar appearance synced only after attach via DisposableEffect(dark) reaching through DialogWindowProvider (Presentation.swift:239–244) — producing per-open window cost and a one-frame system-bar flash.

Suggested fix: animate against an estimated/target detent height (subcompose real content during the slide), sync bar appearance synchronously on attach, and/or offer an in-window overlay host so sequential presentations don't repeatedly pay window setup.

Impact

Every sheet/alert/cover open shows: empty frame → geometry-jump frame → content, plus measure latency proportional to sheet body size; while open, presenter churn rebuilds the sheet graph per frame. iOS shows none of these on identical code. For content-heavy sheets the open visibly stutters instead of sliding.

Offer

(a), (b), and (c) look independently PR-able; we're happy to contribute starting with (a)+(c) (memoized evaluate + up-front preference harvest, following your existing backDismissDisabled pattern) if you'd accept them — guidance on preferred approach welcome.

Start with Layout/Presentation.swift at the cited evaluation, preference, and dialog paths, then inspect Containers/PresentationRoot.swift and View/ModifiedContent.swift. Trace the open path for sheets, alerts, and covers; done means the issue's reported empty frame, preference settle frame, repeated presenter evaluation, measurement delay, and per-open window cost are addressed without regressing presentation behavior.