User Profile

So it does! A useful exercise, thank you.A further question: the video pixel buffer color primaries attachment states 'P3 D65' – does that mean that in the context of the shader from the example code, we're in what could be described as an 'sRGB linear extended' color space? i.e a max saturated P3 red will give values of R greater than 1 in the shader?

Thinking some more, maybe just using the animation modifier after passing the SubView some substate is equivalent:SubView(subState: state.subState).animation(MyAnimation())That would be elegant. I'll have to investigate.

That’s actually the first route I took.I have a publisher that produces a large state object (conforming to hashable), so at the root of my view tree I have an onReceive block that passes in the state to a top-level view as a straight struct – right into its initialiser.Where I became stuck was what happens when I want one part of that state update to initiate an explicit animation of one kind, and another part of that state to initiate no animation or some other kind of animation. It’s clear that bindings have the animation modifier. I had hoped that I could use the withAnimation block. But with state passed in as a raw struct to a view’s initialiser, where would that call even go? Ideally they’d be a way to do this.Intuitively , passing in a deep state object as a raw struct, and then passing down partial sub-states into sub-views seems a reasonable strategy with SwiftUI’s diffing behaviour. But I’m struggling to see the hook for specialising animations for partial sections of the view-tree/sub-state. I’ve made use of some onAppear /onDisappear hacks to modify some local @state which then forces an animation – but I don’t feel it’s particularly elegant.

Bindings are intended for both reading and writing. There's no rule that says you must write to the value. Thanks this is really useful. It seems it may be the only choice in the short-term.In the long-term though, I hope we're offered a better solution as it leaves something to be desired.For example, say you create an ObservableObject which has some read-only property you'd like to derive Bindings from to pass down the view-tree:You can't create a WriteableKeyPath to it as it's read-only, which means you can't create a Binding as the Binding subscript requires a WriteableKeyPath. Therefore, the workaround is to create an intermediate computed property which returns the desired state in a 'get' clause, and has some kind of assertion failure in the 'set' clause to warn that this is a binding that shouldn't be written to.I think this will work, but it seems to require a lot of boilerplate for something that should be simple.Ideally, they'd be a read-only counterpart to Binding that could be derived from any read-only KeyPath. That's why I initially thought maybe I had missed something and perhaps a Publisher was supposed to fulfil this role – but it seems a Publisher isn't party to the same kind of treatment a Binding receives in terms of SwiftUI performance optimisations etc. as it's mapped and passed down the view-tree and so this won't work.