Repository navigation
Legend hoverLink emphasis highlighting becomes unresponsive on line series above ~2,000-3,000 points (SVG renderer) #21744
Description
Version
6.0.0
Link to Minimal Reproduction
Steps to Reproduce
Go to https://echarts.apache.org/examples/en/editor.html
Paste the following into the JS tab and click Run:
const POINT_COUNT = 2000; // change to 3000+ to reproduce
const data = [];
let base = +new Date(2023, 0, 1);
let value = 5;
for (let i = 0; i < POINT_COUNT; i++) {
base += 30 * 1000; // 30s interval
value = value + (Math.random() - 0.5) * 4;
if (value < 0) value = Math.abs(value);
data.push([base, Number(value.toFixed(3))]);
}
option = {
tooltip: {
trigger: 'axis',
axisPointer: { type: 'line' }
},
legend: {
bottom: 0,
data: ['Huge Metric (20k points)']
},
grid: {
bottom: 60
},
xAxis: { type: 'time' },
yAxis: { type: 'value' },
dataZoom: [{ type: 'inside' }],
series: [
{
name: 'Huge Metric (20k points)',
type: 'line',
data: data,
symbolSize: 2
}
]
};
With POINT_COUNT = 2000:
Hover the legend text at the bottom → the line highlights/emphasizes correctly. ✅
Hover over the chart body → tooltip/axis-pointer track the cursor smoothly. ✅
Change POINT_COUNT to 3000 (or higher, e.g. 20000) and re-run.
Repeat:
Hover the legend text → no highlight, or highlight is unresponsive. ❌
Hover over the chart body → tooltip/axis-pointer still work correctly. ✅
Current Behavior
When rendering a line series with the SVG renderer and default showSymbol: true, hovering over the legend name (which triggers legend.hoverLink → series emphasis styling) works correctly up to ~2,000 data points, but becomes unresponsive once the series grows to ~3,000+ points.
Note: the axis tooltip/axisPointer (hovering directly over the chart plot area) is not affected — it continues to track the cursor and display values correctly regardless of point count. Only the legend-hover-triggered series emphasis/highlight is impacted.
This appears to be caused by echarts rendering one SVG symbol node (e.g. ) per data point when showSymbol is not explicitly disabled. At larger point counts, re-styling/re-rendering the emphasized series (triggered by legend hover) on that many live SVG DOM nodes becomes too expensive to complete responsively.
Expected Behavior
Hovering the legend name should highlight/emphasize the corresponding series responsively, regardless of point count.
Actual behavior:
At 2,000 points: hovering the legend name immediately highlights/emphasizes the series line.
At 3,000+ points (tested up to 20,000): hovering the legend name produces no visible highlight, or highlighting is significantly delayed/unresponsive. Chart-body hover (tooltip/axis-pointer) remains fully functional at all point counts tested.
Environment
- OS: MAC
- Browser: ChromeAny additional comments?
Workaround found:
Setting showSymbol: false (and optionally sampling: 'lttb') on the series restores legend-hover responsiveness at high point counts, since it avoids rendering one symbol node per data point.
Suggested fix / ask:
Improve default performance of legend hoverLink emphasis re-render at this point-count range without requiring showSymbol: false, or document this threshold in performance guidance for line series with legend interaction.
Activity
helgasoft commentedon Sep 4, 2026
set hoverLayerThreshold = your data count + 45. Works with SVG and Canvas renderer.
Demo
📌 please close issue if problem solved.
ShanteshSindgi commentedon Sep 7, 2026
Its working , Thanks @helgasoft
ShanteshSindgi commentedon Sep 16, 2026
@helgasoft
I have a couple of follow-up questions on choosing the right value, since we need to apply this generically across many charts (varying series counts, axes, legends, toolboxes, dataZoom, etc.):
What is the recommended value / how should it be chosen? The comparison is against the total rendered element count (elCount in updateHoverLayerStatus), not just data points. So a fixed +45 buffer works for large single-series charts but falls short on smaller charts with more chrome (extra axes, legend items, toolbox, dataZoom), where non-data elements alone push elCount past dataCount + 45 and the hover layer re-engages — breaking the highlight again. Is there a recommended way to compute a safe threshold, or a fixed element-count value you'd suggest?
At what point should the hover layer be enabled? The docs describe hoverLayerThreshold (default 3000) as a canvas repaint optimization ("avoid re-painting the whole canvas," "extra canvas," "burden on mobile devices"). On the SVG renderer, does raising this threshold (or setting it very high to keep the hover layer off) carry any real performance/memory cost? Or is the hover layer essentially a canvas-only optimization that has little benefit under SVG — in which case is it safe to keep it disabled regardless of element count?
Essentially: for the SVG renderer, is there a concrete element-count number above which enabling the hover layer is actually beneficial, or should it just stay off?
helgasoft commentedon Sep 16, 2026
Since I'm not an ECharts developer, I hardly ever look "under the hood" in their source code.
Through experiments, I discovered the "magic number" of 45. It is a minimum value; you could try using higher values for various charts.
Because the API does not adequately explain hoverLayerThreshold, we struggle with these workarounds. I hope the developers are aware of this.
ShanteshSindgi commentedon Sep 17, 2026
Reopening this — the hoverLayerThreshold workaround from @helgasoft does restore legend-hover highlighting on the SVG renderer, but I'd like maintainer guidance before relying on it, since the docs don't fully describe this behavior.
Questions:
Is the underlying breakage a bug you intend to fix? Should legend hoverLink emphasis stay responsive regardless of point count without needing a hoverLayerThreshold override? If a fix is planned, we'd rather wait for it than hard-code a threshold.
How should the threshold value be chosen? From updateHoverLayerStatus, the threshold is compared against the chart's total rendered element count (elCount), not just data points. So a fixed offset like dataCount + 45 under-counts on charts with extra axes/legend/toolbox/dataZoom, and the hover layer re-engages unexpectedly (re-breaking the highlight). Is there a recommended way to compute a safe value, or an intended fixed element-count value?
Does the hover layer apply to the SVG renderer at all? The docs describe it purely as a canvas optimization ("avoid re-painting the whole canvas", "extra canvas", "burden on mobile devices"), yet in practice the threshold clearly affects SVG legend-hover highlighting. Is the hover layer meant to be active under SVG, or is the SVG breakage an unintended side effect? And on SVG, is keeping the hover layer off (high threshold) safe with no real memory/perf cost?
plainheart commentedon Sep 18, 2026
@100pah may explain the details if available.
tevinch commentedon Sep 21, 2026
ECharts 6.1.0 already has a renderer guard for this:
updateHoverLayerStatusreturns immediately when the renderer is not Canvas. For SVG on that release, there is nodataCount + 45buffer to calculate for this optimization.I compared the official npm 6.0.0 and 6.1.0 bundles in a Chrome regression harness, keeping SVG,
showSymbol: true, all data points, and the default threshold of 3000. The 6.0.0 comparison reproduced the missing emphasis at 3,000 and 20,000 points. On 6.1.0, legend hover and restoration worked at 2,000, 3,000 and 20,000 points, including after legend hide/show, zooming, and asetOptiondata update. A two-series case with two axes, toolbox and slider also passed, and the axis tooltip remained usable.If your application can upgrade, try the official 6.1.0 release with the threshold override removed. SVG still has the cost of drawing the symbols; these checks establish the interaction behavior, not a universal performance or memory guarantee.
helgasoft commentedon Sep 21, 2026
@tevinch, thank you for digging deeper into it. To summarize your findings about 6.1.0 :
elCount depends on chart content, it could be calculated after rendering is done - Demo
tevinch commentedon Sep 22, 2026
A small correction to point 2:
elCountcounts non-group elements (if (!el.isGroup)), and the threshold check is strictlyelCount > hoverLayerThreshold. Equality also leaves this threshold-based hover layer off at that update.My regression results above cover SVG only. They do not establish Canvas correctness after disabling the layer, or that a count sampled after one render stays sufficient after changes to chart content. For the original SVG case on 6.1.0, the renderer guard avoids this threshold calculation entirely.