apache / echarts

Apache ECharts is a powerful, interactive charting and data visualization library for browser
https://echarts.apache.org
Apache License 2.0
60.15k stars 19.6k forks source link

[Bug] Flickering while scrolling #19610

Open wrfz opened 7 months ago

wrfz commented 7 months ago

Version

5.4.3

Link to Minimal Reproduction

https://echarts.apache.org/examples/en/editor.html?c=area-time-axis&version=5.4.3

Steps to Reproduce

Issue is reproduceible with official Examples. Open for example the Large Area Chart

Zoom in with mouse wheel or change dataZoom-> end property for example to 0.1:

dataZoom: [ { type: 'inside', start: 0, end: 0.1 },

Move the diagram with the mouse alternately to the left and right.

Current Behavior

If you move the dialog box slowly, the border segments suddenly disappear / appear. This is already strange and not as expected.

If you move the chart back and forth quickly, you will get a very unpleasant flickering.

Expected Behavior

The edge segments should not suddenly appear/disappear, but should always be drawn up to the edge of the diagram.

Environment

- OS: Windows
- Browser: Chrome and Firefox

Any additional comments?

No response

wrfz commented 7 months ago

Flickering

You can see the effect on the GIF. However, you can't see it as a flicker because the GIF fps is too low.

helgasoft commented 7 months ago

try animation:false in series. 📌 please close issue if problem solved.

MatthiasMert commented 7 months ago

it has to do with the filterMode of the dataZoom component. If a datapoint is moved out of the grid it will be treated like it doesnt exist, thus the white edge border (size depending on how far the next datapoint is to the grid border). Set filterMode: 'none' to disable this behaviour.

wrfz commented 7 months ago

try animation:false in series. 📌 please close issue if problem solved.

series: [
    {
      animation: false
    }

That doesn't help. Flickering is still there.

wrfz commented 7 months ago

it has to do with the filterMode of the dataZoom component. If a datapoint is moved out of the grid it will be treated like it doesnt exist, thus the white edge border (size depending on how far the next datapoint is to the grid border). Set filterMode: 'none' to disable this behaviour.

If I set filterMode to none, this is not the behavior I want. It is then no longer filtered at all. It makes scrolling the chart very sluggish.

What I would expect is that the filter should take place, but only the data that does not affect the visible area should be filtered / clipped. Currently the filtering affects the first and last visible value in the graph. And that feels broken.

MatthiasMert commented 7 months ago

Currently the filtering affects the first and last visible value in the graph. And that feels broken.

filtering doesnt affect any visable values and the observed behaviour is not a bug. Its a little unfortunate in the case of a line graph with area.

What you want seems to be a new feature that allows to set the filterMode separately for the x- and y-axis. Since you want filtering along the y-axis but not on the x-axis.

wrfz commented 7 months ago

Thank you for you feedback. I'm not really familiar with ECharts yet. I only discovered this great library 2 days ago. What I need is that the chart is always drawn to the end. The two red areas should also always be painted over. One more value should always be taken into account. This would then certainly draw out of the graph area, which would require the use of clipping. I have no idea whether clipping is always used in ECharts or whether it is deliberately avoided for performance reasons.

wrfz commented 7 months ago

To clarify once again, ECharts currently behaves as follows:

Instead, I would expect the behavior on left and right edge to be something like this:

helgasoft commented 7 months ago

The flickering on both sides comes from redrawing the fill areas. And the redrawing is due to filterMode being 'filter'. Change the code to

  yAxis: { max:175, min:0 },
  dataZoom: [{ type: 'inside', filterMode:'none', start: 0,  end: 0.1 },

and you'll see no flickering, but of course the yAxis range will not cover all values. @MatthiasMert's idea of a new filter by axis is a good one. Then we would have dataZoom: [{ xFilterMode:'none', yFilterMode:'filter' }] and obtain the effect you want for the entire X axis.

wrfz commented 7 months ago

I don't think we understand each other. I don't think "redrawing" is the reason. If you scroll slowly, you can see the effect much more clearly:

Here the area is either filled or not, depending on the current scroll position. Perhaps you see/describe the effect as "redrawing". For me, "redrawing" is when something is painted over.

The actual chart line is also drawn at the edge or it is not, depending on the scroll position. In addition, you can see at the bottom of the X-axis that hourly data appears and disappears again when scrolling, which leads to additional flickering on the X-achsis when scrolling quickly. I think that the X-axis should only move the displayed values and not increase or decrease the level of detail when scrolling. This is probably because the two lateral values are sometimes cut off and sometimes not. This means that you have constantly changing conditions when scrolling the visible area. For this reason, the chart line also "wobbles" slightly, as the data basis is constantly changing for the interpolation algorithm.

filterMode:'none' has a massive impact on performance. Moving the chart becomes very sluggish and not nearly as smooth. I assume that (without filtering) all data is iterated over, even though most of it is not visible. When switching off the filtering, it seems to me that the FPS deteriorates by a factor of 2 (or more). If you have a lot of data outside the visible area, then it is also understandable, that the FPS goes down if you don't filter it out. It is therefore legitimate and sensible to filter out data that is irrelevant to the visible area.

If I had to use filterMode:'node' to prevent flickering, then unfortunately ECharts is not suitable for my purposes for performance reasons. That would be a great pity.