HN Explorer

16 comments

[ 4.5 ms ] story [ 182 ms ] thread
k__
Do I understand this correctly.

This is some "on the fly" computation?

Like, people could add computing power to a process just by surfing to a webpage?

rwinn
Not exactly, it is a task queue that allows workers to be run in the browser.

If you could break your problem up in to lots of small isolated tasks it could be used like that

stygiansonic
Based on a quick inspection (WS opened, binary frames going over it, and CPU utilization), this appears to be the case.

A very interesting way to do distributed computing!

forgotmypassw
The animation makes the browser tab so jaggy I can barely scroll down to read more.
rwinn
That sucks. I'm using d3.js to animate svg elements, runs smoothly on my machine, what browser/os are you on?
forgotmypassw
FF Nightly on Windows, I also checked on my laptop running Linux and the same thing happens so I guess it's related to the browser specifically.
rwinn
Yep, I can reproduce it on OS X with FF 42.0 as well. Going to see if i can find what's causing the low framerate.
[dead] creshal
> Going to see if i can find what's causing the low framerate.

Gee, I dunno, maybe running a pointless flashy animation to represent something that doesn't need any?

Gigablah
You might want to check out what's causing your constipation.
fulafel
On Ubuntu it's fast in Chrome and slow in Firefox.
rwinn
Found the problem and pushed a fix, should me much smoother now.

It was Firefox's SVGPathElement::getPointAtLength implementation that was slow, working around it by caching all the calls to it.

rwinn
Btw, if anyone is wondering why the workers run so slow when in a background tab, it is because most browsers throttle setTimeout's to run max once a second when the browser window looses focus. (web workers does not have this problem but for the demo i figured it would be fun to watch the workers do their thing)