I feel like I’ve noticed this a decent amount in SwiftUI apps; random 1-second delays which really feels like they shouldn’t exist. The settings app in Ventura, for example, makes you wait any time you switch settings screen just to show what looks like a pretty basic interface. Given the complexity of what’s being drawn, time from clicking until the new screen is displayed should be much closer to 10ms.
I suppose the delay isn’t due to the drawing, but rather the figuring out of what to draw. Which seems to be one of the difficulties of working with SwiftUI - it’s easy to build something that technically works, but is very inefficient.
Things like in the article, where too many things depend on irrelevant changes. I suppose that’s something that XCode could try to expose in better ways, but I imagine it’s a tricky problem.
I wonder if this is also true for flutter. It also feels like doing a lot of great work in terms of usability for developers, but I can easily imagine this coming at a greater cost (which may be totally irrelevant depending on the size of your app).
Is Flutter reactive? I suspect this problem occurs in all reactive-type UI frameworks, because tracking and updating dependent components can be expensive, and eliminating unnecessary View invalidation & redraw is difficult. I’ve definitely seen this kind of jank occur in the past in older Apple frameworks with dependency-based updating (i.e. Key-Value Observing), such as Cocoa Bindings and Core Data.
Yep it is. It also had some funny problems like jumping in its grid-to-pixel mapping until recently on windows, which I think shows some of the problems or behavior.
Personally I hate the kind of animation the author so loves. XD I turn them off whenever possible. Some animations are useful, but…
I feel like I’ve noticed this a decent amount in SwiftUI apps; random 1-second delays which really feels like they shouldn’t exist. The settings app in Ventura, for example, makes you wait any time you switch settings screen just to show what looks like a pretty basic interface. Given the complexity of what’s being drawn, time from clicking until the new screen is displayed should be much closer to 10ms.
I suppose the delay isn’t due to the drawing, but rather the figuring out of what to draw. Which seems to be one of the difficulties of working with SwiftUI - it’s easy to build something that technically works, but is very inefficient.
Things like in the article, where too many things depend on irrelevant changes. I suppose that’s something that XCode could try to expose in better ways, but I imagine it’s a tricky problem.
I wonder if this is also true for flutter. It also feels like doing a lot of great work in terms of usability for developers, but I can easily imagine this coming at a greater cost (which may be totally irrelevant depending on the size of your app).
Is Flutter reactive? I suspect this problem occurs in all reactive-type UI frameworks, because tracking and updating dependent components can be expensive, and eliminating unnecessary View invalidation & redraw is difficult. I’ve definitely seen this kind of jank occur in the past in older Apple frameworks with dependency-based updating (i.e. Key-Value Observing), such as Cocoa Bindings and Core Data.
Yep it is. It also had some funny problems like jumping in its grid-to-pixel mapping until recently on windows, which I think shows some of the problems or behavior.