Use rendered path geometry for curved mark interaction

[gillkyle]

Problem

Curved marks look smooth, but hover selection currently tests the straight polygon connecting their original data points.

In a curved stacked-area chart, the cursor can be visibly inside the top layer while the tooltip selects the layer underneath it.

This PR makes hover selection follow the curve that was actually drawn.

Approach

• Store the rendered path on the final scene mark.
• Use that same path for SVG, Canvas, React Native, and hover selection.
• Keep the existing selection rules: painted shape first, then paint order, then the mark's normal x/y fallback.

Built-in D3 curves get this automatically. Custom marks can use scenePath.

CleanShot.2026-08-02.at.17.26.59.mp4

Cost

Every row below is a TanStack Charts bundle or consumer:

TanStack bundle	Gzip change
Browser chart runtime	+292 B
React line-chart consumer	+312 B
Standalone hover resolver	+270 B
Core entry without path interaction	0 B
TanStack curved-line example using a D3 curve	−674 B

The last row shrinks because our old adapter bundled D3's full line and area generators. The new recorder calls the D3 curve function directly, allowing those larger generators to tree-shake out. This is a TanStack implementation saving, not a comparison against D3.

Curved selection is about 0.3 µs slower per query (3.6 vs 3.3 µs). Point-only selection is unchanged. bundle:check remains red because the standalone resolver is 227 B over its existing 2 KiB budget; this draft leaves that trade-off visible for review.

Validated with 775 tests, typecheck, package/docs checks, production build, benchmarks, and live SVG/Canvas checks.

Not included: frame-by-frame animated picking or parsing arbitrary SVG path strings.

[coderabbitai]

Important

Review skipped

Draft detected.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: f294111b-34aa-4464-998c-4ceed8e8e433

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[tannerlinsley]

@gillkyle, the shared path recorder is useful for the curved-bar work in #202 too. I tested the recorder at 412836ce704f6332bf17330097264d385ef50b27 and found a smaller flatness check worth considering:

return (
  squaredDistanceToSegment(x0, y0, x3, y3, x1, y1) <=
    pathTolerance * pathTolerance &&
  squaredDistanceToSegment(x0, y0, x3, y3, x2, y2) <=
    pathTolerance * pathTolerance
)

This checks both control points against the finite endpoint segment, so it does not flatten collinear overshoots or loops into one chord. It reuses the existing helper and leaves the rendered path string, tolerance, and depth limit unchanged.

In isolated Chromium, Firefox, and WebKit runs, 2,003 directed/random cubics with 201 samples each stayed within the existing 0.25px tolerance. The largest sampled candidate error was 0.187px. A deliberately broken always-flat control failed on a collinear overshoot.

For a 720px-wide, 10,000-point oscillating basis curve, contour points fell from 114,279 to 18,299. Direct PR-versus-candidate timings for ten constructions, two warmup pairs and eight alternating measured pairs, were 50.5 → 23.8ms in Chromium, 70 → 43ms in Firefox, and 57 → 27ms in WebKit. Path strings matched. These are construction-only measurements, not whole-chart performance claims.

The standalone scenePath export also fell from 3.326 to 3.271 minified kB, 1.402 to 1.362 gzip kB, and 1.273 to 1.245 Brotli kB. I have not applied this to your branch or run the full checkout/consumer matrix, so this does not clear the PR's bundle or CI gates.

One separate shared limitation to keep in mind for #202: the interaction callback has no clip context. The existing max(shapeDistance, clipDistance) fallback can select a fully clipped-out triangle whose bounding box still intersects the clip. That predates this recorder work, so I am tracking it separately rather than asking this PR to solve arbitrary clipped geometry.

[tannerlinsley]

Thanks @gillkyle, I completed the full isolated checkout checks at this head: 807 DOM tests, all six additional framework targets, TypeScript and the documentation contract pass. The packed-consumer gate passes too, including bare React Native and Expo, and all seven adapter package gates pass. These are this older 0.6.2 checkout’s own checks, not validation of a rebase onto current main.

The actual packed scenePath export also passes 603 sampled distance checks across three directed cubics, including an overshoot and a loop, plus a closed-path control. Flattening those curves to one chord makes the verifier fail.

The bundle check passes against the PR’s proposed limits. That does not approve the increases or apply the optional flatness optimization above. I have left the draft status unchanged; required CI, budget decisions and validation against the eventual merge base still remain.

Verified head: 412836ce704f6332bf17330097264d385ef50b27.