Shape.bounds returns incorrect rectangle

[mhdhejazi]

Consider the following simple shape:
<path d="M160 80.3848C160 187.051 0 187.051 0 80.3848C0 -26.2819 160 -26.2819 160 80.3848Z" fill="#C4C4C4"/>

As you can see the size is 160x160, but when I call Shape.bounds it returns:
x: 0.000000, y: -26.281900, w: 160.000000, h: 213.332900

If we check the curves of this path closely we can understand what's happening. The returned rectangle is bigger because it also includes the control points:

I checked how the bounds are calculated and found out that the native method CGContext. boundingBoxOfPath is the culprit since it calculates the bounding box for all the points including the control points:

CGContext.boundingBoxOfPath

The bounding box is the smallest rectangle completely enclosing all points in a path, including control points for Bézier cubic and quadratic curves.

While CGPath.boundingBoxOfPath, despite having the exact same name, doesn't include the control points in the calculation:

CGPath.boundingBoxOfPath

The path bounding box is the smallest rectangle completely enclosing all points in the path but not including control points for Bézier and quadratic curves.

I tried using ctx.path?.boundingBoxOfPath instead of ctx.boundingBoxOfPath here:

Macaw/Source/model/scene/Shape.swift

Line 68 in 3acbaff

var rect = ctx.boundingBoxOfPath

and it returned the correct result:
x: 0.000000, y: 0.384775, w: 160.000000, h: 159.999675

Searching for boundingBoxOfPath in this repo I found out that Path.bounds() actually uses the correct method:

Macaw/Source/model/geom2d/Path.swift

Lines 15 to 17 in 3acbaff

	override open func bounds() -> Rect {
	return toCGPath().boundingBoxOfPath.toMacaw()
	}

So I think this method can be used as a workaround until this is fixed (instead of Shape.bounds, one can use Shape.form.bounds()).

[ystrot]

Hi @mhdhejazi,

Thanks for detailed description! I've pushed a fix.

[ystrot]

Actually it's not that easy. We have simple sample in tests:

<path d="M10,10C40,10,65,10,95,80S150,150,180,80"/>

And on this sample both CGPath.boundingBoxOfPath and CGContext. boundingBoxOfPath works incorrectly (blue is path bounds, red is context bounds):

In this case we need to use context, because at least it returns a bounding box. It's not minimal, but path bounding box completely wrong. So I'll revert this change and we need to wait Apple will fix it.

[mhdhejazi]

I see.
But it's confusing that Shape.bounds doesn't return the same value as Path.bounds(). The former returns the bigger rectangle in your example, while the later returns the smaller one.

[ystrot]

Agree, but it's the best we can do. In Path.bounds we don't have context, so we need to use path method.