stackotter

Hmm weird, I thought I had fixed display scaling support a while ago. I’ll have to look at that again. Thanks for investigating further!

I'm going to revive this very old issue as our layout performance tracking issue. I'll document performance improvements ideas that I have here, until the layout performance becomes acceptable, at...

I believe that changing the compute layout function to compute a single size from a size proposal, like SwiftUI does, rather than computing the size, ideal size, minimum size, and...

LayoutSystem (which houses the stack layout algorithm) is where we need to focus our attention to improve layout performance. At the moment it has a 'branching factor' of 3 (even...

Another source of layout performance issues is certain single-child views such as ScrollView (and maybe some modifiers) that have a branching factor higher than 1 (i.e. they call their child's...

> I believe that changing the compute layout function to compute a single size from a size proposal, like SwiftUI does, rather than computing the size, ideal size, minimum size,...

Another worthwhile change would be to split once-off 'start of update' logic out of view update methods and into a separate 'beginUpdate' method that we guarantee to call once and...

I've figured out how SwiftUI does layout so efficiently I think, but it's not very satisfying. It just uses a bunch of approximations that are kinda easy to trick. For...

#273 adds layout performance benchmarks that allow us to track layout performance improvements over time.

Once we start tracking the dependencies of view builder expressions, we should only recompute scene/view body closures when their dependencies change, rather than having our code recompute them on every...