feat: support render contributions for line graphic

[g1f9]

🤔 This is a ...

• New feature

🔗 Related issue link

None — happy to open one if preferred.

💡 Background and solution

DefaultCanvasLineRender is the only canvas graphic renderer that never resolves or invokes render contributions:

• its constructor takes no IContributionProvider and never calls this.init()
• neither drawSegmentItem() nor drawLinearLineHighPerformance() calls beforeRenderStep() / afterRenderStep()
• consequently there is no LineRenderContribution symbol at all

Every other canvas renderer supports it — rect, arc, area, symbol, path, polygon, text, image, circle, star, richtext all call the hooks (see base-render.ts). line looks like an oversight rather than a decision: it already extends BaseRender, so the hook methods are inherited, just never called.

Why this matters: render contributions are the supported way to draw extra passes around a graphic (DefaultBaseBackgroundRenderContribution, the texture contributions and the interactive contribution all use it). Today anything built on that extension point silently skips line marks, so line/radar series can't participate in effects that every other mark type can.

This PR wires line up exactly the way rect is wired:

• add ILineRenderContribution type and the LineRenderContribution symbol
• DefaultCanvasLineRender now accepts an IContributionProvider and calls init()
• bindLineRenderModule creates the contribution provider and calls bindContributionProvider
• both draw paths invoke beforeRenderStep() / afterRenderStep()
• drawSegmentItem() now receives drawContext so contributions get the same arguments they get on other graphics

No behaviour change when no contribution is registered — with an empty builtinContributions the added calls iterate over an empty list.

📝 Changelog

Language	Changelog
🇺🇸 English	Support render contributions for the line graphic
🇨🇳 Chinese	支持 line 图元的渲染贡献扩展点

☑️ Self Check before Merge

• Doc is updated/provided or not needed
• Demo is updated/provided or not needed
• TypeScript definition is updated/provided or not needed
• Changelog is provided or not needed

🧪 Verification

Verified against @visactor/vrender-core@1.1.10 by applying the equivalent change to the published bundle and registering a contribution on LineRenderContribution in a real VChart page:

• before: line graphics never reached any contribution (0 invocations across every chart type)
• after: the contribution is invoked on line graphics (268 invocations in one render pass) and its extra draw pass is visible on screen, including line marks and pie leader lines

[xile611]

@g1f9 The line extension point makes sense, but this revision is not ready to merge. It introduces core compilation errors, misses the incremental renderer wiring, changes clipping behavior even without a custom contribution, and does not expose the active segment's attributes to contributions. Details and reproduction results are in the four inline comments.

Validation against head 838ab47f and base 69d82c11:

• tsc --noEmit --incremental false --composite false --pretty false in packages/vrender-core passes on the base and reports five errors on the PR: four TS2345 errors at line-render.ts:123/154/212/243, plus TS2554 at runtime-installer.ts:172.
• With ts-jest type diagnostics disabled specifically to inspect runtime behavior, 24 existing targeted registry/contribution tests pass. Nine additional review probes produce four passes (normal linear, curved, clipRange, and segmented hook invocation) and five failures covering visibility arguments, clip-path preservation, segment attributes, incremental provider wiring, and incremental hook invocation.
• Comparing the same clipping input with the base renderer confirms the regression: the base strokes the polyline; this revision strokes the rectangular clip path instead.
• Both build workflows currently fail; Unit test CI stops during the build before running tests.

Please address these issues, add regression coverage, and get CI green before merging. A small draw/pick benchmark would also help assess the added work on the high-performance line path: BaseRender.init() adds two built-in clip contributions, so the no-custom-contribution case does not iterate over empty lists.

[xile611]

[P1] Pass computed visibility flags, not opacity values

The seventh/eighth hook arguments are fVisible and sVisible booleans, but these calls pass numeric fillOpacity/strokeOpacity. All four new calls fail TypeScript compilation (lines 123, 154, 212, and 243). This is also a semantic problem: a line with fill: false and strokeOpacity: 0.5 delivers [doFill, doStroke, fVisible, sVisible] = [false, true, 1, 0.5], rather than [false, true, false, true]. Please propagate the computed fill/stroke eligibility and visibility values, accounting for fill presence, overall opacity, and line width; merely coercing the opacity values to booleans would not fix the contract.

[xile611]

[P1] Update the incremental renderer factory for this required dependency

DefaultIncrementalCanvasLineRender inherits this constructor, but configureRuntimeApplicationForApp() still calls new DefaultIncrementalCanvasLineRender() at src/entries/runtime-installer.ts:172. The PR therefore adds TS2554 and leaves the incremental renderer without the registered line contributions at runtime. Please wire the LineRenderContribution provider through that factory, as is already done for area. There is a second incremental-path gap to cover: even with a provider supplied, drawIncreaseSegment() never invokes either hook (verified with a contribution spy while an actual stroke occurs). Making the constructor parameter optional alone would hide the missing wiring rather than complete it.

[xile611]

[P2] Preserve the line path when enabling the built-in clipping contribution

BaseRender.init() always adds the before/after clip contributions, even when builtinContributions and the provider are empty. Consequently this new call activates DefaultBaseClipRenderBeforeContribution after the line path has already been constructed. For a line with clipConfig: { shape: 'rect' }, that contribution calls beginPath() and builds the clip rectangle; the subsequent context.stroke() then strokes the rectangle instead of the line. A recording-context comparison on the same input yields moveTo, lineTo, lineTo on the base and rect, closePath on this revision. Please preserve/reconstruct the graphic path across clipping and add a no-custom-contribution regression test. The same ordering needs checking in drawSegmentItem().

[xile611]

[P2] Expose the active segment attributes to per-segment contributions

For a segmented line, attribute is the current segment while defaultAttribute is [lineAttribute, line.attribute]. The hook receives only the whole line and that array cast to a single required attribute object; the current segment is omitted. A style-dependent extra pass cannot reliably determine which segment's stroke/lineWidth/opacity it should use. In a reproduction with a black parent stroke and red/blue segment overrides, resolving styles from the hook inputs yields black for both passes. Please provide the active segment attributes explicitly to both hooks (the existing area renderer passes { attribute } in the final argument), and test differing segment styles. The type assertion alone does not make the array conform to the advertised attribute-object contract.

[g1f9]

Thanks for the very detailed review — every one of the four points reproduced. Pushed d7c069c and 40be361.

[P1] Visibility flags — BaseRender.valid() already returns { doFill, doStroke, fVisible, sVisible }, and drawShape() was already calling it and discarding the result (there was even a commented-out destructuring left in the file). That result is now threaded into both drawSegmentItem() and drawLinearLineHighPerformance() and handed to the hooks, so your example — fill: false with strokeOpacity: 0.5 — now yields [false, true, false, true]. The four TS2345 errors are gone.

[P1] Incremental wiring — both halves are covered. runtime-installer.ts:172 now passes a LineRenderContribution provider exactly the way the sibling incremental area renderer right below it does, and drawIncreaseSegment() now invokes beforeRenderStep()/afterRenderStep() with the flags drawShape() had already computed. I did not take the optional-parameter shortcut, for the reason you gave.

[P2] Clip path — reproduced exactly as described. Path construction now lives in a local buildPath() that is replayed after the hook when clipConfig is present, so stroke() paints the polyline again. Applied to all three paths (drawSegmentItem, drawLinearLineHighPerformance, drawIncreaseSegment).

One consequence worth your call: clipConfig now actually takes effect on lines. Before this PR the line renderer never ran the hooks, so the built-in clip contribution never fired and the attribute was silently ignored on line. The new behaviour looks like the correct one to me, but it is a behaviour change relative to the base, and I am happy to gate it if you would rather keep strict parity.

[P2] Segment attributes — both hooks now receive { attribute } as the trailing argument, matching area-render.ts. In your red/blue segment repro the two passes now resolve to red and blue.

Verification

Run locally on this branch:

check	result
tsc --noEmit --incremental false --composite false --pretty false in packages/vrender-core	0 errors (was 5)
rush build --only tag:package	success
rush test --only tag:package	success
packages/vrender-core jest	110 suites / 643 tests passed, 0 failed

__tests__/unit/render/line-render-contribution.test.ts adds five cases: the unchanged no-contribution drawing sequence, the clipConfig regression, the visibility-argument contract, per-segment attributes, and the incremental wiring. I injected each bug back in one at a time and confirmed the corresponding test fails, so none of them is vacuous.

Benchmark

__tests__/perf/line-render-contribution-performance.test.ts, following the existing opt-in convention (VRENDER_LINE_RENDER_PERF=1, skipped by default like attribute-model-performance). It compares the high-performance path against a subclass with both hooks stubbed out, with no custom contribution registered — so the measured cost is exactly the built-in clip contributions being iterated rather than an empty list.

200-point line, 2000 draws per round, 9 rounds, minimum per variant, three separate runs:

+0.041 us/draw  (+4.44%)
+0.034 us/draw  (+3.66%)
+0.040 us/draw  (+4.31%)

Two caveats on reading that number. The context is a no-op stub, so real canvas work is excluded and the percentage is an upper bound relative to real rendering. And the two variants have to be interleaved: measuring them in sequence charges JIT warmup to whichever runs first, which in my first attempt produced a negative overhead.

Happy to take another pass if any of this is not what you had in mind.

[xile611]

Re-reviewed head 40be3619 against base 69d82c11. The previous compilation errors, incremental provider/hook wiring, visibility argument types, segment-attribute propagation, and painted-path preservation are now fixed.

One P2 remains: activating the built-in clip contribution also changes line picking. An unfilled line now reports a hit in empty space inside the clip rectangle. This reproduces with both Canvas and Math line pickers and no custom contribution; see the inline comment.

Validation:

• Core tsc --noEmit --incremental false --composite false --pretty false: passed.
• Six targeted suites, including the PR's new tests, runtime contribution tests, and review probes: 47 tests passed; two new regression checks failed, one for each picker. The same picking input returns false with the base renderer and true with this head. Curved, partial clipRange, segmented, closed, and incremental painted-path preservation checks passed.
• Unit test CI is green. The automatic Bug Server run fails at upload with an invalid-token response; it provides no screenshot-regression result for this head.

Please fix the clip/picker interaction and add coverage for empty space inside the clip as well as the actual visible stroke before merging.

[xile611]

[P2] Keep the clip path from becoming the line's hit region

Forwarding the picker callbacks into this newly activated hook makes DefaultBaseClipRenderBeforeContribution call fillCb(..., true) on the clip path, even when the line has fill: false. BaseLinePicker then latches picked = true for any point inside that path; the Math picker's PickerBase additionally marks the clip test final. Rebuilding the line path afterward cannot undo that result, so hovering/clicking empty space selects the line.

Reproduced without custom contributions using points [{x:0,y:0},{x:50,y:30},{x:100,y:0}], stroke: 'red', fill: false, lineWidth: 1, pickStrokeBuffer: 0, and clipConfig: {shape: 'rect'}. Calling either DefaultCanvasLinePicker.contains or DefaultMathLinePicker.contains at {x:50,y:5} with EmptyContext2d returns true on this head, versus false with the base renderer. The point is well away from the stroke. The same callback forwarding is present in drawSegmentItem().

Please make clipping constrain the actual line hit test instead of supplying a filled hit region, and add picker regressions alongside the painted-path tests.