CGPath描边lineWidth是否存在上限？超上限会引发描边异常吗？

Great question—this is a super common gotcha when working with thick stroke widths on complex CGPaths, especially those derived from glyphs via CTFontCreatePathForGlyph. Let’s break this down:

Is there a hard limit for lineWidth? #

Officially, Core Graphics doesn’t define a numerical upper limit for lineWidth. You can set it to any positive CGFloat value. However, practical rendering limits absolutely exist, and exceeding them will lead to artifacts like the holes you’re seeing.

Why do holes appear with large lineWidth? #

The issue boils down to geometric computation limitations and the complexity of your glyph paths:

• Path detail vs. stroke size: Glyph paths are made of tiny segments, sharp corners, and sometimes overlapping subpaths. When your lineWidth becomes larger than the length of these small segments, or larger than the inner radius of a corner (especially with round joins/caps, which use a radius of lineWidth/2), the renderer struggles to calculate the stroke’s filled area accurately.
• Floating-point precision errors: Core Graphics uses floating-point math for path calculations. As lineWidth grows, small precision errors in path coordinates or stroke geometry get amplified, leading to gaps or overlapping regions that cancel each other out (creating holes).
• Round join/cap interactions: With round joins, the renderer tries to smooth corners by adding a circular arc. If the corner’s internal angle is too sharp, or the adjacent segments are too short, the arc calculation can fail to fill the intended area, leaving holes.

Fixes for your glyph path scenario #

If you need thick strokes on glyph paths, here are the most reliable workarounds:

• Convert stroke to a filled path: Instead of stroking the original glyph path, precompute the stroked outline as a new path and fill it. Use CGPathCreateCopyByStrokingPath with the same lineWidth, lineCap, lineJoin, and miterLimit settings you were using. This bypasses real-time stroke calculation issues, as you’re now filling a solid shape instead of computing a stroke dynamically.
• Simplify the glyph path: Remove tiny segments (those shorter than lineWidth/2) or merge overlapping subpaths before stroking. This reduces the complexity the renderer has to handle, minimizing precision errors.
• Adjust coordinate space: If you’re rendering at a non-1x scale, try normalizing the path to a unit coordinate space first, applying the stroke, then scaling it up. This can reduce floating-point precision drift.

内容的提问来源于stack exchange，提问作者aunindo