Repository navigation
[Bug] Tooltip performance issue with multiple "line" series on Windows + Chromium #21784
Description
Version
6.1.0
Link to Minimal Reproduction
https://codepen.io/kirchsuSICKAG/pen/PwpEBvV
Steps to Reproduce
- Use ECharts 6.1.0 with a current Chrome or Edge on Windows device.
- Create a line chart with tooltip.trigger: 'axis' and at least two line series, better visible on more.
- Use jagged data, such as independently generated random values between 0 and 100.
- Set the chart height to about 700 px and use 2,000 data points per series.
- Move the mouse across the plot area. Observe that the tooltip and axis pointer lag behind the cursor or move in visible jumps. The lag becomes worse as more line series are added.
- Repeat with
tooltip: { trigger: 'axis', showContent: false }. The axis pointer still lags, so the issue is not limited to displaying the tooltip content. - Repeat with DevTools open. The lag becomes more noticeable.
- For comparison, try a 300 px chart, one line series, gradual rather than jagged data, Firefox on Windows, or Chrome/Edge on macOS. These cases showed no lag in my tests.
For testing all this things out, have a look at my codepen example.
Current Behavior
When the mouse moves over the plot area, the tooltip and axis pointer visibly lag behind or jump instead of following the cursor smoothly, if using a Windows device in a chromium browser (Chrome / Edge). The lag is most noticeable the more jagged line series are used. It becomes more severe as the number of series, the chart height increases or the browser dev console is open.
The issue is reproducible with both the Canvas and SVG renderers. The axis pointer still lags when tooltip content is disabled with tooltip.showContent: false, so the issue is not limited to rendering the tooltip content.
In the tested configurations, the chart remained smooth with a 300 px height but lagged at 700 px. Jagged, abruptly changing data caused more lag than gradual data. Moving the series into separate value ranges did not eliminate the lag, so overlapping lines are not required to reproduce it. Opening DevTools makes the lag more noticeable.
The same chart was smooth in Firefox on Windows and in Chrome and Edge on macOS.
Workaround
In my reproduction, the lag is not reproducible by applying these options:
axisPointer: {
zlevel: 10,
triggerEmphasis: false
},
series: [{
// ...
emphasis: {
disabled: true
}
}]
### Expected Behavior
The tooltip and axis pointer should follow mouse movement smoothly across chart sizes and series counts for all browsers, without the need of disabling emphasis.
### Environment
```markdown
- OS:Windows
- Browser: Chrome and Edge
- Framework: allAny additional comments?
Windows - Chrome
Chrome_Windows.mp4
Windows - Firefox
Firefox_windwos.mp4
MAC - Chrome
Activity
helgasoft commentedon Oct 9, 2026
This is a "lag problem in certain browsers" more than a bug, IMHO. It is reasonable to anticipate lags in proportion to the quantity of data.
And the workaround could be called "fixing the problem with appropriate settings".
BTW adding
tooltip: { trigger: "axis", displayTransition: false, transitionDuration: 0 },makes it even snappier 🚀kirchsuSICKAG commentedon Oct 22, 2026
@helgasoft Sorry for the late response and thanks for you feedback.
I investigated the issue further and managed to reproduce it with plain ZRender: https://codepen.io/kirchsuSICKAG/pen/JoWZzXe?editors=1110
Since the same behavior can be reproduced without ECharts, it seems that the performance cost might be related to ZRender state handling rather than the tooltip implementation itself.
From an application perspective, robust behavior across different browser and OS combinations would be valuable. In our use case, we visualize sensor data where several thousand data points per series are not uncommon and we cannot control which browser or operating system our customers use. For that reason, even if the issue is browser-specific, it would be interesting to understand whether there is an opportunity to improve the underlying interaction performance.
I'd be interested to hear your thoughts.
helgasoft commentedon Oct 22, 2026
@kirchsuSICKAG, here is what I think.
Using only ZRender is interesting and impressive. The most time-consuming code is in applyAxisEmphasis and clearEmphasis.
If the three
lines.forEachinside are commented out, there is no lag in Chrome. So the problem is in highligh/downplay large line series with "several thousand data points per series". Which is a design choice I do not understand since it degrades user experience substantially.kirchsuSICKAG commentedon Oct 23, 2026
@helgasoft
As some background on our situation: I'm part of a design system team in a large company. We provide chart components that use ECharts as the underlying charting library and apply our own defaults and styling through a custom theme.
The challenge for us is that we do not always know how application teams will use these components. In many cases, they simply consume the component and rely on the default behavior that we provide.
If the recommendation is to disable highlight/emphasis for large datasets, we essentially have two options:
I agree with your observation that repeatedly highlighting large line series is the expensive operation and can negatively impact the user experience.
The difficulty for us is that both small and large datasets are common in our domain. For many charts, the default highlight and emphasis behavior works well and provides a good user experience. At the same time, we also have use cases involving sensor data with several thousand values per series, where the same defaults can become problematic.
Since we cannot reliably predict which use case downstream applications will have, nor which browser or operating system their customers will use, finding the right default behavior becomes challenging. From my perspective, it would therefore be valuable if the interaction remained as robust as possible across different browser/OS combinations, even for larger datasets.
That said, I agree with your analysis that the expensive part appears to be the highlight/downplay path rather than the tooltip itself.
helgasoft commentedon Oct 23, 2026
A compromise solution for both small and large datasets is to count all data points and disable highlight/downplay when that count is over a certain threshold value. Similar to progressiveThreshold.
kirchsuSICKAG commentedon Oct 27, 2026
Thanks for the suggestion. I'll add a note to our documentation about this possible performance problem and ways to handle it for larger datasets.
Still, I think it could be beneficial if this could somehow be addressed on the ECharts / zrender side as well. Otherwise, every application using larger datasets may eventually run into the same behavior and needs to consider whether and when to disable highlight/emphasis individually. Either having a fix directly in zrender or having a mechanism in ECharts itself, potentially similar to the threshold approach you suggested, could provide a more robust default behavior for all users.