Rendering issue for very small nodes

[OskarGroth]

First off, really great work! This component is awesome and it captures many advantages of using SwiftUI vs CA/CG 🙌

I'm having an issue when rendering data sets where some nodes are a lot larger than others.

Consider the demo project with this data set:

    let configuration = SunburstConfiguration(nodes: [
        Node(name: "Walking", showName: false, image: UIImage(named: "walking"), value: 4078656, backgroundColor: .systemBlue),
        Node(name: "Restaurant", showName: false, image: UIImage(named: "eating"), value: 3203440, backgroundColor: .systemRed),
        Node(name: "Home", showName: false, image: UIImage(named: "house"), value: 45.0, backgroundColor: .systemTeal, children: [
            Node(name: "San Francisco", showName: false, value: 15.0, backgroundColor: .systemTeal, children: [
                Node(name: "Twin Peaks", showName: false, value: 3.0, backgroundColor: .systemOrange),
                Node(name: "Hayes Valley", showName: false, value: 1.5, backgroundColor: .systemOrange),
                Node(name: "Nob Hill", showName: false, value: 8.0, backgroundColor: .systemOrange),
            ]),
        ]),
    ], calculationMode: .parentDependent(totalValue: nil))

The expected behaviour would be to see 2 arcs, Walking and Restaurant, and a third Home that is so thin it should almost not be visible. However, the result is this:

This behaviour seems to be related to the start angle, as changing it seems to affect the behaviour:

If the ArcMinimumAngle setting was implemented, this effect could be mitigated. But it might still be worth trying to figure out the source of this issue.

[OskarGroth]

It seems the bug is caused by the margins being larger than the arc width, causing startAngle to be larger than endAngle when creating the Path in ArcView.

Changing configureViews to only list arcs that fulfill if (arc.start + arc.innerMargin) < (arc.end - arc.innerMargin) will fix the issue:

private func configureViews(arcs: [Sunburst.Arc], parentArc: Sunburst.Arc? = nil) -> some View {
    return ForEach(arcs) { arc in
        if (arc.start + arc.innerMargin) < (arc.end - arc.innerMargin) {
            ArcView(arc: arc, configuration: self.sunburst.configuration).tapAction {
                if self.sunburst.configuration.selectedNode === arc.node && self.sunburst.configuration.focusedNode === arc.node {
                    self.sunburst.configuration.focusedNode = self.sunburst.configuration.parentForNode(arc.node)
                } else if self.sunburst.configuration.selectedNode === arc.node {
                    self.sunburst.configuration.focusedNode = arc.node
                } else {
                    self.sunburst.configuration.selectedNode = arc.node
                }
            }
            IfLet(arc.childArcs) { childArcs in
                AnyView(self.configureViews(arcs: childArcs, parentArc: arc))
            }
        }
    }
}

But it's not an optimal solution since it creates gaps as seen in the gif. Ideally there should be some functionality that can be shared with the implementation of a ArcMinimumAngle setting to not display certain nodes and have the rest adjust their position accordingly.

[lludo]

Oh, thank you for pointing this out! Yes this is exactly right, the margin is creating some issues as it is "taking away" the size from the arc itself (half on each side). I ran into this same issue when reducing the inner radius close to 0.

I'll look at this more in depth this week to see what could be the best option here.

[lludo]

I updated for Xcode 11 beta 4. And the wrapping all the way around (because start > end, with the margins) should be fixed too. Can you confirm that it is fixed on your side too ?

[OskarGroth]

Thanks @lludo. I've just tried it out and it seems some functionality has been lost.
This is the behaviour I get when tapping on arcs (first red, then yellow):

[lludo]

Just noticed this too, looks like changes are now delayed after the following event. This is probably due to the change in beta 4 where BindableObject is now using willChange instead of didChange. I'm investigating that now.

[lludo]

Everything should be behaving as expected now! 🎉