Hacker News new | past | comments | ask | show | jobs | submit login

The 150ms benchmark in the title is really selling this short, the performance is very impressive. The 150ms seem to refer to the time it takes to initialize the graph, and with a hot cache that is more like 50ms for me here. Redrawing seems much, much faster.

I have done some visualization with WebGL because I couldn't get it fast enough with just drawing lines. That was a while ago so I'm not sure about the details, but even a simple prototype just drawing a few tens of thousands to a hundred thousand lines using canvas was slower than this for me (subjectively).

I'll have to look at the code later, but I'm curious about where this library is getting the performance from. Before I saw this I would have said you can't do this at this speed without using previously downsampled version of the data points, I'm not entirely sure now.

I'm still looking at the performance tab in the browser dev tools and how impressively empty the main Javascript usage plot is.




It looks like the mouse lines and the selection highlight are just partially-transparent divs stacked on top of the canvas that get moved around, so nothing actually gets redrawn unless the date range changes (which is a pretty clever approach!).


but really tricky to align correctly at different screen pixel densities and rounding errors. it's still not pixel-perfect, but i decided it was good enough.


That's something I expected, you really don't want to trigger redraws on mouse over. What surprised me was that I couldn't tell the the times where I zoomed in or out from the JS flame chart. Usually that is really obvious, but in this case zooming was so fast that you could hardly see it. And this graph has probably around ~194k data points (388k in the source data, I assume that's x and y). I'm not entirely sure about the number of points here, I'm taking that from the json delivered to the site.

The selection highlight is unusual, I admit. That's something I'd just skip if I were going for high performance.


> And this graph has probably around ~194k data points

no, the top graph is pretty much what the title says: 3 * 365 * 24.

but 194k is also no problem :)


> I'll have to look at the code later, but I'm curious about where this library is getting the performance from.

https://news.ycombinator.com/item?id=23047156




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: