[BUG] Rendering errors in a Line chart at specific responsive widths

[rinogo]

Expected Behavior

In these particular charts, there is only one non-zero datapoint in each data set. The expected behavior is for all data points to be zero (at the bottom of the chart) and a single data point in each data set at the right side of the chart. This should result in a simple "triangle" shape as follows:

Additionally, here is an animated gif demonstrating the "load" functionality at a specific responsive width that works without issue. Everything looks good:

Animated: https://www.dropbox.com/s/fatvz6nyv3caya6/chartjs-rendering-ok-loading-animation.gif?dl=0

Current Behavior

At certain responsive widths, the chart renders correctly. However, at other widths, an extra area is drawn from the first data point. As you can see from the "hovered" data point, ChartJS seems to be aware of the correct data points, but the actual colored area on the chart does not match up with the data:

Here are some animated gifs demonstrating the issue. First, resizing the window through various responsive widths demonstrates the chart changing between correct and incorrect rendering states:

Animated: https://www.dropbox.com/s/7byctatrx0mpwtd/chartjs-rendering-errors.gif?dl=0

Additionally, here is an animated gif demonstrating the "load" functionality at a specific responsive width that has issues. You can see strange glitching as the chart animates:

Animated: https://www.dropbox.com/s/p4mdvxwxx0efwet/chartjs-rendering-errors-loading-animation.gif?dl=0

Possible Solution

I'm not sure what the problem is. It's odd that the chart displays correctly at some widths, but at other widths does not.

Steps to Reproduce (for bugs)

I haven't created a public reproduction yet. If this does, indeed, look like a new bug, I can provide access to our password-protected app for inspection or try to set up a separate reproduction case.

Context

These rendering errors cause misleading visualization of data in ChartJS. 😢

Environment

• Chart.js version: 2.7.1
• Browser name and version: Chrome 66, Firefox 59 (all on on macOS 10.12.6)
• Link to your project: Private password-protected portal, access can be provided for inspection if necessary

[etimberg]

@rinogo do you know if this reproduces in 2.7.2 as well?

Is it possible to create a version with just the chart in a fiddle with any sensitive data removed?

[rinogo]

I was able to take some time to set up a pen. I haven't "cleaned up" the code, but this at least allows for consistent bug repro outside of our app.

When accessing this pen, resize your browser's width to see the chart alternate between "ok" and "buggy" states.

https://codepen.io/rinogo/pen/yjKEOa

[rinogo]

Any updates on when this could be investigated a bit more?

[simonbrunel]

Any reason to use tension: 0.0000001 instead of 0? It seems to be the cause of your issue.

[rinogo]

@simonbrunel Yes, I believe that fixes the problem!

https://codepen.io/rinogo/pen/dKygMy

I'm not sure why 0.0000001 was used instead of 0. The code was inherited from another project. I'd guess that it was used due to some idiosyncrasy of Chart.JS. Regardless, changing the value from 0.0000001 to 0 "fixes" the problem and doesn't seem to cause any ill-effects. Thank you so much! :)

[simonbrunel]

One reason why it was 0.0000001 could be because when 0, Bézier control points are not computed and thus it's not possible to animate tension from 0 to another value (and vice-versa). Setting something very close to 0 will generate Bézier curves and animate correctly.

Actually, that can be my fault because I'm using this workaround in some example to enable tension animation. We should certainly try to handle this case of very small tension or find a way to animate to and from 0.

[rinogo]

Excellent background info. Thanks again! :)