It's been troubling me too. We might never achieve lower latency unless using UIUpdateLink (WWDC24 What’s new in UIKit). However, I failed to trigger that low-latency mode. I think low-latency rendering on iOS seems designed for drawing apps.

Oh perhaps this is just because Stage Manager's 3D mode (Show Recent Apps) works terribly in Metal 4? That 3D animation is expected to consume much less GPU and power.

The behavior of UIUpdateLink is kind of weird. _ UIUpdateLink.isEnabled: By default, the value of this property is true. No. I must explicitly write updateLink.isEnabled = true for all cases. _ @MainActor var wantsImmediatePresentation: Bool { get set } Hmm, yes and no. Setting this property DOESN'T WORK. I wonder if this intended why there's even isImmediatePresentationExpected.

Days passed and I've been accustomed to use open with environment variables. Well, a plist key for MTL_HUD_ELEMENTS would be trivial for me… But I rely on Metal HUD pretty much. With this I could easily tell when my XDR display went into bad mood. (Game graphics stuttering during brightness change in XDR displays)

Also some games may capture input, making configuration panel (Metal HUD > Show Configuration Panel) particularly hard to use.

I did't fully read the documentation and misunderstood this API. Scene.windowIdealSize(_:) is for zooming in macOS. (The command "Window" > "Zoom" can trigger it.) This also explains why there exists WindowIdealSize.maximum, I think. For my needs, I used Scene.defaultSize and people would see my designed window size on first-time window presentation. WindowGroup { Color.accentColor.opacity(1/4) .frame(minWidth: 500, minHeight: 500) .frame(idealWidth: 800, idealHeight: 800) } // For window zooming (a macOS feature), // which can be accessed via double-clicking the window title bar (see Settings). .windowIdealSize(.fitToContent) // For window size on first presentation .defaultSize(width: 640, height: 640) In this example, people will see 640640 window for the first time. Also, when people zoom this window, it expands to 800800, not as large as it can.

Problems gone 16.4 beta (16F1t). Seems working fine on all macOS.

Problem persists and behaves in the same way in a fresh macOS 15.5 beta (24F5042g). I used UTM as a Virtualization environment. bringing approximately 2 watts of power load to my Mac I'm new to Apple silicon therefore I wrongly measured the power consumption. It seems to be 0.15W ~ 0.2W on M4 and 6W on virtualized M4.