In my app there are two main layers both animate. Due to performance reasons the lower of the two layers is completely opaque and animates at 12fps via a TimelineView. It has a lot of views that move per frame however everything moves slowly so that lower frame rate is fine.
The second layer however has only one View and uses a Canvas rather than various SwiftUI views. It however does look better running at 60fps. It fills the screen but is mostly transparent.
My hope would be that despite having the 60fps layer on top that the lower layer is still invalidating at a lower frame rate. I would furthermore hope that the compositing step would recognize it doesn't need to re-render layer one for a least half of the frames and can just composite layer two on top.
Does anyone happen to know how SwiftUI and layout step and render server behave in this scenario?
Thanks for describing both layers and the rate each one needs. The SwiftUI and Core Animation documentation doesn't describe the behavior you're asking about. It says nothing about how often SwiftUI re-evaluates one view while a sibling animates faster. It also says nothing about whether the system reuses unchanged content when it composites the screen. Because of that, I can't tell you what to expect, and anything you observe today could change in a future release. The published APIs are a firmer basis for design decisions.
The documentation for the schedule you're using, animation(minimumInterval:paused:), describes "a pausable schedule of dates updating at a frequency no more quickly than the provided interval." That sets an upper limit on how often your 12 fps content updates. The schedule doesn't promise that rate, and its documentation says nothing about other views on screen.
For content that moves slowly and continuously, the SwiftUI Animation API is another option. You change a state value and attach an animation, and SwiftUI animates the view from the old value to the new one. Optimizing iPhone and iPad apps to support ProMotion displays states that "the system automatically handles frame pacing for UIKit, SpriteKit, SwiftUI, and CAAnimation animations for you."
For more precise control over frame rates, the published APIs offer custom drawing with Metal, driven by a CADisplayLink. The same article describes how to request a rate by setting the display link's preferredFrameRateRange. The article recommends keeping display links to a minimum and grouping animations with similar timings in one display link. The requested rate is still a hint rather than a guarantee. The article cautions that your app "must not assume that Core Animation calls your CADisplayLink callback at any specific refresh rate or even at the rate requested."
It also explains why an app can't rely on any specific frame rate. In the article's words, "you can't force a ProMotion display to show your content at any specific rate." Display refresh rates "can change for many reasons," and "your app can't presume a specific refresh rate at any time." For example, the system disables faster refresh rates in Low Power Mode or when the device gets hot.
The article recommends that you "do your own testing on an actual device to make sure your animations look good." The Animation Hitches and SwiftUI templates in Instruments show how your layers perform on a specific device and release.