Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fast Fill #462

Merged
merged 1 commit into from Nov 16, 2014
Merged

Fast Fill #462

merged 1 commit into from Nov 16, 2014

Conversation

danvk
Copy link
Owner

@danvk danvk commented Nov 11, 2014

Fixes #346

There are two main "innovations" here:

  1. The chart fill is now drawn in a sane order (see my comment on issue Setting "fillGraph" results in considerable slowdown for complex charts #346 for a chart)
  2. I created an optimizing canvas renderer, which drops superfluous points on their way to the canvas.

I took screenshots of tests/dense-fill.html both with and without the optimization. There were a few differences with the antialiasing along the edges, but nothing visually distinguishable.

The performance improvement can be dramatic. For a 10,000 point series in a 480x320 chart (i.e. the benchmark), I see a drop from ~700ms/draw → 25ms/draw, which is roughly in line with the performance w/o fillGraph set.

The speedup is entirely explained by the number of line segments being sent to the canvas. tests/dense-fill.html draws a 10,000 point series on an 800px wide canvas. Before, it issued 40,000 moveTo and lineTo calls. After, it issues ~1490.

for (var i = 0; i < pendingActions.length - 1; /* incremented internally */) {
var action = pendingActions[i];
if (action[0] == MOVE_TO && pendingActions[i + 1][0] == MOVE_TO) {
pendingActions.splice(i, 1);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fascinating that these splices are fast.

Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As it turns out, JavaScript is pretty fast these days!

That's changed substantially since dygraphs started. Working w/ ReactJS has really changed my mentality. Everything that's done in pure-JS land is fast. Everything that touches the DOM is slow.

@kberg
Copy link
Collaborator

kberg commented Nov 16, 2014

I get the basics here, LGTM, but I can't do a detailed review. :/

This is done by introducing a "fast canvas proxy", which elides
redundant moveTo and lineTo calls. This also reworks the order in which
the points are drawn to be more amenable to this optimization.
danvk added a commit that referenced this pull request Nov 16, 2014
@danvk danvk merged commit ce0b116 into master Nov 16, 2014
@mirabilos mirabilos deleted the fast-fill branch January 13, 2023 20:18
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Setting "fillGraph" results in considerable slowdown for complex charts
2 participants