JamesGoslings opened a new pull request, #21616:
URL: https://github.com/apache/echarts/pull/21616
## Brief Information
This pull request is in the type of:
- [x] bug fixing
- [ ] new feature
- [ ] others
### 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
- #21614 : [Bug] Line chart tiny segments skipped, becoming a slope
## Details
### Before: What was the problem?
`drawSegment` in `src/chart/line/poly.ts` drops any segment whose squared
pixel distance is `< 0.5` as a render-time optimization:
```ts
// Ignore tiny segment.
if ((dx * dx + dy * dy) < 0.5) {
idx += dir;
continue;
}
```
For plain polylines this is harmless. For step lines, however,
`turnPointsIntoStep` expands 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.5` threshold.
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 `step` flag is propagated from `LineView` through `ECPolyline`/`ECPolygon`
shapes into `drawSegment`. In step mode the function now only drops strictly
duplicate points (`dx === 0 && dy === 0`) and keeps every other corner intact:
```ts
// Ignore tiny segment.
// In step mode, keep every corner; only drop strict duplicates. See #21614.
if (step) {
if (dx === 0 && dy === 0) {
idx += dir;
continue;
}
}
else if ((dx * dx + dy * dy) < 0.5) {
idx += dir;
continue;
}
```
Non-step rendering is byte-for-byte identical.
Added a unit test `test/ut/spec/series/line-step-poly.test.ts` that records
the path commands emitted for a step-expanded point set matching the #21614
reproduction and asserts:
1. Step mode visits the corner before the tail (regression for #21614).
2. Step mode still collapses strictly duplicated points so the path stays
clean.
3. Non-step mode still applies the `< 0.5` tiny-segment optimization.
Verification:
- Without the fix, the corner-visit assertion fails with the exact bug
behavior (corner is missing, only the tail `lineTo` is emitted).
- With the fix, the new tests pass.
- Full unit test suite: `Test Suites: 25 passed, 25 total; Tests: 188
passed, 188 total`.
- `npm run lint` and `tsc --noEmit` both pass (also enforced by the
project's pre-commit hook).
## Document Info
One of the following should be checked.
- [x] This PR doesn't relate to document changes
- [ ] The document should be updated later
- [ ] The document changes have been made in apache/echarts-doc#xxx
## Misc
### Security Checking
- [ ] This PR uses security-sensitive Web APIs.
### ZRender Changes
- [ ] This PR depends on ZRender changes (ecomfe/zrender#xxx).
### Related test cases or examples to use the new APIs
N.A.
### Merging options
- [x] Please squash the commits into a single one when merging.
### Other information
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
