Layout correctness

[stackotter]

ScrollView

Scroll view layout is surprisingly tricky. The main complicating factor is choosing whether or not to include the scroll bars. In certain situations, it can look like you've made the wrong choice regardless of whether you choose to include the scroll bars or not. For example, if you have a view of constant aspect ratio inside a scroll view, and the scroll view is slightly too short to fit the view, then you must show the scroll bars, but the act of showing the scroll bar decreases the width of the scroll view's content, and therefore its height due to its constant aspect ratio, causing the scroll bar to appear useless. The only consistent choice to make is to include the scroll bar, cause otherwise the content will overflow. Last time I checked, SwiftUI handled this edge case worse than SwiftCrossUI. It ends up flickering between having the scroll bar and not having it constantly. I believe that SwiftCrossUI handles the situation correctly, just not efficiently, but I'll have to double check.

I've included this edge case because it's something that we have to make sure we still handle correctly after optimising the ScrollView layout implementation.

Ideal width VStacks (and ideal height HStacks)

Ideal width VStacks with a proposed height (and equivalent HStacks) are tricky to lay out consistently. The expected behaviour, in English terms, is that the stack should allocate its height to its children as usual (greedily) while letting each child take on its ideal width. Then the stack should take on the width of the widest child and all other children should expand their widths to match the widest element. The issue is that giving the children more width could cause the the heights of the children to change, causing a knock-on effect of each child getting proposals that differ more and more from the original proposals. I don't believe that there's a way to solve the problem perfectly without at least having a closed form for the sizing behaviour of each child of the stack. You either have to risk under-utilising the proposed height, or not have the widths laid out how you might expect, or both.

I noticed this issue while trying to spec out SwiftCrossUI's layout algorithm a bit better. The first time that I tried to test out this edge case, I instantly managed to break SwiftUI's layout algorithm.

---

It's kinda interesting that these issues that I noticed on paper are real issues faced by SwiftUI. I think we can handle them better than SwiftUI.

---

I'll update this issue as I find more edge cases.

[helje5]

You can find the ScrollView behavior documented over here: https://www.swiftuifieldguide.com/layout/scrollview/

[stackotter]

SwiftUI's handling of ideal width VStacks

It appears that SwiftUI doesn't reuse its original height proposals. Once it has determined a width it'd like to use for the VStack (using the widest ideal width of any of its children with heights assigned as usual), it runs another layout pass using that chosen width as if that chosen width is a regular width proposal. Once completed it uses the chosen width along with the total height used by the original pass (not the subsequent pass) as the size of the VStack. This sometimes leads to the VStack not hugging its contents. This could be the correct behaviour? Although I would've expected the VStack to hug its contents no matter what.

[helje5]

it would be helpful if you could provide a small swiftui example that demonstrates the unexpected behavior.
But yes, a container can query the children for various sizes. And in the end it will place them in the last pass.

[stackotter]

Here's a repository containing some reproducers for the issues I discussed in the issue so far: https://github.com/stackotter/swiftui-layout-edge-cases

It contains an example of the scroll bar flickering exhibited by SwiftUI, which requires a mouse to be connected to your Mac to happen.

It also contains two slightly different examples of odd layout behaviour happening when you give some admittedly weird stack layouts a fixedSize along their orthogonal axis, with a non-fixedSize layout axis.

[stackotter]

Regarding my previous comment about SwiftUI's handling of ideal width VStacks.

I think SwiftUI uses the original predicted size as the actual size (instead of the real actual size which it does know by the end of the layout process) because it reduces the amount of computation you have to do before you know the size of the stack. You only have to do the second layout pass once when you commit the layout to the screen. That said, I think we should at least centre the content of the VStack in its slightly incorrect bounds if we take this approach.