netscout-mthorn commented on PR #21646: URL: https://github.com/apache/echarts/pull/21646#issuecomment-4671936540
One issue I am seeing when using this feature in practice: tick crowding near zero when `splitNumber` thinning is active. With `logMapping: 'symlog'`, `logBase: 10`, `logLinearWidth: 1`, `splitNumber: 5`, and a data range of roughly -168M to 303M, the stride calculation produces `effectiveBase = 10^4 = 10000`. The candidate ticks that fall within the extent are: `-100M, -10K, -1, 0, 1, 10K, 100M` In transformed (pixel) space, the gaps between consecutive ticks are highly unequal: | Gap | Fraction of axis height | |-----|------------------------| | -100M → -10K | ~25% | | -10K → -1 | ~23% | | **-1 → 0** | **~2%** | | **0 → 1** | **~2%** | | 1 → 10K | ~23% | | 10K → 100M | ~25% | The `-1`, `0`, and `1` labels are all crammed into roughly 4% of the axis, making them unreadable. The screenshot below shows this with `hideOverlap` disabled, then with it enabled. <img width="553" height="208" alt="Screenshot 2026-06-10 at 11 46 15 AM" src="https://github.com/user-attachments/assets/561f9c14-ed83-4d12-90a3-fe544ee3c823"; /> The workaround I am currently using is `axisLabel.hideOverlap: true`, which suppresses the crowded labels. It works well enough in practice, which raises the question of whether this is actually a problem worth fixing at the tick generation level — or whether `hideOverlap` is simply the right tool for this situation and the tick placement is correct by design. If it is worth addressing, two approaches come to mind: **1. Skip `a0` when stride > 1.** When thinning is active, `+-a0` is negligibly close to zero relative to the rest of the axis. Starting the candidate sequence at `+-a0 * effectiveBase` instead of `+-a0` would ensure the first tick past zero is always spaced consistently with its neighbors. The downside is losing the explicit linear/log boundary marker, though in practice most users are unlikely to notice it. **2. Post-process by minimum transformed gap.** After generating candidates, compute the spacing between adjacent ticks in transformed space and drop any whose gap to its neighbor falls below some threshold fraction of the total axis span. More general than (1) and would also catch edge cases where the data extent itself produces crowding, but introduces an arbitrary threshold that would need to be a new option or a sensible constant. Not sure whether either of these belongs in this PR or a follow-up. Happy to hear thoughts. -- 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]
