fix(line): keep step corners when adjacent points are visually close#21616
fix(line): keep step corners when adjacent points are visually close#21616JamesGoslings wants to merge 1 commit into
Conversation
…lose apache#21614 The drawSegment helper in line/poly.ts drops segments whose squared pixel distance is below 0.5 as a render-time optimization. For regular polylines this is harmless, but step lines (produced by turnPointsIntoStep) rely on every emitted point to define the corners of the stair-case. When two consecutive data points are very close on the base axis, the auxiliary corner points fall under the threshold and get skipped, collapsing the L-shape into a diagonal slope. Propagate a `step` flag from LineView through ECPolyline/ECPolygon shapes into drawSegment, and in step mode only drop strictly duplicate points (dx === 0 && dy === 0). Non-step rendering is unchanged. Adds a unit test that records the path commands emitted for a step configuration matching the reproduction in apache#21614 and asserts that the corner is visited before the tail.
|
Thanks for your contribution! Please DO NOT commit the files in dist, i18n, and ssr/client/dist folders in a non-release pull request. These folders are for release use only. |
There was a problem hiding this comment.
Pull request overview
Fixes a rendering edge case in the line polyline renderer where step (staircase) lines could incorrectly collapse into a diagonal when adjacent step-expanded points are within the tiny-segment skip threshold, restoring correct corner preservation for step mode (issue #21614).
Changes:
- Propagates a
stepflag fromLineViewintoECPolyline/ECPolygonshapes to inform rendering behavior. - Adjusts
drawSegmentto keep all non-duplicate segments in step mode (dropping only strict duplicates), while keeping the existing tiny-segment optimization for non-step mode. - Adds a unit test that asserts step corners are preserved, strict duplicates are still collapsed, and non-step optimization remains intact.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
src/chart/line/poly.ts |
Updates segment-skipping logic to preserve step corners and wires a step hint into drawSegment. |
src/chart/line/LineView.ts |
Sets shape.step on the polyline/polygon based on the series step option. |
test/ut/spec/series/line-step-poly.test.ts |
Adds regression/unit coverage for step-corner preservation and related segment skipping behavior. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
The changes brought by this PR can be previewed at: https://echarts.apache.org/examples/editor?version=PR-21616@84a4a3f |
Brief Information
This pull request is in the type of:
What does this PR do?
Stop the line renderer from collapsing step (stair-case) lines into diagonal slopes when adjacent data points are very close on the base axis.
Fixed issues
Details
Before: What was the problem?
drawSegmentinsrc/chart/line/poly.tsdrops any segment whose squared pixel distance is< 0.5as a render-time optimization:For plain polylines this is harmless. For step lines, however,
turnPointsIntoStepexpands each data segment into an L-shape by inserting an auxiliary corner point. Those corner points encode the stair-case and must all be visited.When two consecutive data points are very close on the base axis (e.g.
[08:59:30, 1]and[09:00:00, 1]reported in #21614), both the corner and one or more intermediate auxiliary points fall under the< 0.5threshold. They all get skipped, so the renderer goes straight from the previous point to the next far point, drawing a diagonal slope instead of a vertical step.Reproduction from the issue (CodeSandbox): https://codesandbox.io/p/sandbox/pdh82y?file=%2Findex.js
The reporter also already pinpointed the offending line:
src/chart/line/poly.ts:83.After: How does it behave after the fixing?
A
stepflag is propagated fromLineViewthroughECPolyline/ECPolygonshapes intodrawSegment. In step mode the function now only drops strictly duplicate points (dx === 0 && dy === 0) and keeps every other corner intact:Non-step rendering is byte-for-byte identical.
Added a unit test
test/ut/spec/series/line-step-poly.test.tsthat records the path commands emitted for a step-expanded point set matching the #21614 reproduction and asserts:< 0.5tiny-segment optimization.Verification:
lineTois emitted).Test Suites: 25 passed, 25 total; Tests: 188 passed, 188 total.npm run lintandtsc --noEmitboth pass (also enforced by the project's pre-commit hook).Document Info
One of the following should be checked.
Misc
Security Checking
ZRender Changes
Related test cases or examples to use the new APIs
N.A.
Merging options
Other information