I would like to work on

• Change require to import

Should I do this within the current code base (may take a day for the whole projet, I could start during the upcomming weekend) aka master?

@SebastianNiemann I think that's the best way to do it. We've already started merging breaking changes to master. If we need to do 2.9.x hotfixes we'll do that in a separate branch.

@benmccann @kurkle thoughts?

Yes, go for it! I would love that :-)

Chart.js currently struggles with hover / live value display in large datasets. Might want to also look into this.

https://github.com/leeoniya/uPlot#performance

Good suggestion! I filed #6716 to discuss and track that issue

Should we consider dropping IE support? It would make some new things available:
Proxy - for data change detection
Map - for array uniqueness (if we can't get rid of it). Its quite a lot faster really compared jsperfs test of it. (uPlot arrayUnique in ~25ms isntead of ~150ms)

Another thing worth exploring is ResizeObserver. That could be used, instead of current implementation, if supported.

As much as I'd love to drop IE, I think there are still too many IE 11 users. The main website I'm working on right now has ~5% of traffic in IE. But it'd be great to use Proxy, Map, or ResizeObserver when they're available and fallback to the current methods for IE!

I recall ResizeObserver not working entirely for div resizing last time I investigated a few years ago.

as another datapoint, our IE11 traffic for the past 2 weeks has been 2.65%, it was 5.62% for the same period last year. (usa, ecommerce, home remodeling industry).

at some point, as a lib/web author you gotta ask yourself whether maintaining IE11 compat further delays its inevitable death.

For Map, you can just use it directly and have babel take care of polyfilling it.

Hello - is there any movement towards enabling Chart.js to be used inside a web worker controlling an offscreencanvas? I've seen this issue: #5355. If it's appropriate I'd be interested in taking on the necessary work to get it working. Let me know if there's anywhere I should get started! I'll probably be submitting some speculative PRs for this soon.

Context: a major project that we'll be taking on for https://github.com/cruise-automation/webviz in the near future is moving our Chart panel behind a web worker for performance reasons. We use Chart.js currently and love it, and we'd like to keep using it.

@davidswinegar I haven't tried anything yet. However, I think the limitations would be similar to those for server-side rendering. I know that has been done a fair bit with Chart.js (example: https://github.com/shellyln/chart.js-node-ssr-example).

I think you would need to disable resizing since that needs access to the DOM. I also don't know if window.devicePixelRatio is available in a worker. One thing that would need dev work would be switching the canvas context on an existing chart. I think this would let you do:

1. Render initial chart offscreen
2. Copy the offscreen canvas image to the onscreen canvas
3. Point the chart instance to the onscreen canvas to allow interactivity

I am curious though, are you hitting performance bottlenecks in Chart.js itself? If so, you might like to try the latest code from master (will eventually release as v3) because @kurkle and @benmccann have been doing lots of performance improvements.

@etimberg thanks for the info! I am hitting performance issues in Chart.js, though I'm not sure if it's because of the library itself or the fundamental cost of drawing on the canvas. I'll do some benchmarks on the code that's in master and see how it affects us.

Sounds good. There are lots of breaking changes in master, and docs on those are https://www.chartjs.org/docs/master/getting-started/v3-migration.html

Most of the work in 2.x is not related to drawing on the canvas. I think most of that work can be removed. A good chunk already has been. After that's done I don't know if web workers would still provide benefit?

If you use the version from master, which is much faster please see the updated performance documentation to make sure you set options that result in maximum performance. Most of the work has tested on improving line chart performance though many of those improvements help all charts generally. I'd be interested in any feedback you have if you try out what's in master (see the migration guide as there have been numerous changes) and how far off we are to meet your goals.

I tried the version in master and followed the performance documentation and I definitely noticed an improvement! Thanks for the feedback., Our product requirements mean that this improvement won't be enough, though, and that we'll still have to put Chart.js behind a web worker. I'll take this to Slack to work through some approaches on the details.

For context, we're updating 5+ charts many times a second and attempting to play back data in real-time without dropping any data; our performance characteristics need to be closer to games than to analytics web applications. Regardless of how performant Chart.js is, passing data over a web-worker connection and drawing it from there is necessary for us to squeeze every cycle out of the browser - if we were writing our own performance optimized canvas library we'd still have to do this.

@davidswinegar if these are line charts, you can try uPlot to get an idea of what's possible in terms of performance.

I'm aiming to get about another 10x increase in performance. I have a handful of pending PRs that are all geared towards improving performance. I'm happy discuss the web worker approach or any other perf ideas over Slack as you suggested

I'm aiming to get about another 10x increase in performance.

😮 that would be impressive! uPlot is currently at 40ms, Chart.js master is 305ms. 10x faster would be 25% faster than uPlot and i'm not really sure where i can shave a full 10ms!

@leeoniya your numbers look impressive! I think that Chart.js is the choice for us because of support for panning & zooming, and more chart types, but I'll keep uPlot in mind.

Re 10x: It depends which charts you're drawing, what dates you're comparing (e.g. master now is already significantly faster than master yesterday), etc. Plus, I said "about" so if I get 7-8x faster and round up I'll be pretty happy... ;-)

@davidswinegar depending how much you want to experiment you can try grabbing my two pending PRs. It gets Chart.js line charts from 550ms down to 100ms on the uPlot benchmark on my machine compared to 70ms for uPlot: #6881 (comment). The "fastline" PR may be released as an external plugin rather than being merged into core, but should allow you to use other plugins with it still such as zoom/pan, etc. I'm curious what other chart types and scale types you use. I've been most focused on optimizing the time scale and line charts since that's what I use most myself

options.onClick is now limited to the chart area

I've seen that going to v3, the onClick function will be limited to chart area.
I've implemented specific functions in order to catch click events on axes and title because it could be helpful.

Do you think this new feature could be re-thought again?
Will this reduction of events scope apply to onHover as well?

You can hook on the canvas click even directly to catch all clicks.
onHover might be changed too, it should only fire when an element is hovered.
Workaround will be similar, you can use mousemove event of the canvas.

You can hook on the canvas click even directly to catch all clicks.
onHover might be changed too, it should only fire when an element is hovered.
Workaround will be similar, you can use mousemove event of the canvas.

But in this case you have more listeners instead of one. It sounds redundant, in my opinion.
Anyway if you are going to this implementation, there is not other way, I guess.
What I can suggest here is if you are limiting the scope of click event to chart area, it could be better to do the same for onHover as well, to be consistent.
That means all events (defined at options level) have got chart area scope.

API Documentation generated and verified by TypeScript

What does that mean exactly? Because I don't see any type definitions on the alpha branch.

Regards,
Martin, one of the maintainers of @types/chart.js.

It means we generated TypeDocs: https://www.chartjs.org/docs/next/typedoc/. Perhaps we should change "TypeScript" to "TypeDoc" in that sentence to be clearer

After testing v3 alpha version top priority is tree shaking for me. Simply adding one line chart increases bundle size from 6kb to 60kb with gzip 😱

As for user experience, data.datasets[0].data is really frustrating, data word in docs is very confusing. Usingdatasets[0].data seems more logical and understandable.

Everything else worked really well 👍

Hello! I've got one question. Any chance of publishing v2 without Moment as dependency?

You can use v2 without the Moment dependency already today: https://www.chartjs.org/docs/latest/getting-started/integration.html#bundlers-webpack-rollup-etc

@benmccann on a sidenote, I'd hope (and a lot seem to agree) that you could move Support tree shaking / individual module imports up to the "committed features" section. 😍

We would love to have that feature. If anyone would like to volunteer, I'd be happy to discuss what is needed. I can't promise anyone will get to it otherwise since our time is limited, but I do agree it'd be a big improvement

I've played around with the docusaurus build. I don't have any big complaints. @kurkle have you had a chance to look yet?

Is v3 going to include timeline chart? I still didn't see this in the list :(

There's a plugin that someone created for a timeline chart: https://github.com/fanthos/chartjs-chart-timeline (Demo: https://jsfiddle.net/fanthos/8vrme4bt/)

v3 doesn't included any new chart types in the core library. Our focus has been on changes to the core library to make it faster, more configurable, with fewer bugs and edge cases. If there are any changes we can make to the core library to better support plugins like the above then we're happy to consider those changes

Will Charts have a US / World map type of chart?

No, there are no new chart types as explained in my comment just above yours

@Bradley-H I just remembered there's already a plugin for maps: https://github.com/sgratzl/chartjs-chart-geo

I did a little performance testing on my Windows 10 laptop with a i7-8650U @ 1.9GHz and 16GB Ram. I preload data.datasets with 10 datasets containing time stamps and incrementing data points. I then console time around the call to new Chart(). I got the following results:

10,000 pts each (100,000 total) takes 1.5-2s, Chrome uses 520MB
20,000 pts each (200,000 total) takes 3-4s, Chrome uses 1GB
40,000 pts each (400,000 total) takes 7-8s, Chrome uses 1.8GB

So it looks like it's pretty much scaling linearly with the points. I use the following options to increase performance:

  options: {
    spanGaps: true, // enable for all datasets
    animation: false,
    scales: {
      x: {
        type: 'time',
        display: true
      }
    },
    elements: {
      line: {
        tension: 0, // disables bezier curves
        fill: false,
        stepped: false,
        borderDash: []
      },
      point: {
        radius: 0 // default to disabled in all datasets
      }
    }
  }

Since I'm trying to use it for real-time graphing I need as much performance as I can get because 1Hz data for 8hrs is 60 * 60 * 8 = 28,800. If I have 10 items on a graph that would be 280,800 pts. Are there other tricks I can use for performance or other new optimizations in v3.0?

There are performance docs here: https://www.chartjs.org/docs/next/general/performance

You might also try #6881 if performance is really important

However, I would also suggest you probably don't need that many points. Consider, for example, showing one data point per minute instead of one data point per second. If you have more than one point per pixel, I'm not sure how you would get benefit from additional data points after that

Thanks Ben. I think I've implemented most of the performance options. The primary reason we graph so many points is the ability to zoom in and out on the graph. These are real-time graphs so decimating server side and then re-requesting data on zoom doesn't seem possible since the user could then immediately zoom out and resume. Otherwise v3.0.0-alpha worked great!

FYI I created for the following plugins alpha versions targeting v3:

• maps: https://github.com/sgratzl/chartjs-chart-geo
• boxplots: https://github.com/sgratzl/chartjs-chart-boxplot
• pcp: https://github.com/sgratzl/chartjs-chart-pcp
• graphs: https://github.com/sgratzl/chartjs-chart-graph
• error bars: https://github.com/sgratzl/chartjs-chart-error-bars
• hierarchical category scale: https://github.com/sgratzl/chartjs-plugin-hierarchical

Will Charts have a US / World map type of chart?

take a look at https://github.com/sgratzl/chartjs-chart-geo

Following the idea behind #5939 (avoiding misleading charts per default) I would like to suggest to set cubicInterpolationMode to monotone as default.

Wouldn't turning off interpolation all together be even better from that perspective? (i.e. lineTension: 0)

I am ok with lineTension off by default. It was enabled in v2 because it was a default in v1

Hello,
According to docs browser support is the same for Chart.js V3 alpha (Chrome 50+, Firefox 45+, Internet Explorer 11, Edge 14+, Safari 9+). Is that subject to change or it is final plan for Chart.js V3 release?
Thank you.

We are still supporting those browsers