Hacker News Reader

Comment by amelius | Hacker News Reader

Great developments, since, imho, we really need multi-threading to make decent user-interfaces (ones without hick-ups due to blocking of the cpu-resource).

I think what we need is immutable data-structures to be shareable between threads. This approach should also allow structural sharing between threads, allowing for efficient and safe data structures.

Also, I could see a use for a mechanism where a thread creates a data-structure, then marks it as read-only, such that it can become shared.

View on HN

Anecdotally, I've found that most performance hick-ups don't come from computation blocking the ui, but from rendering one part of the ui blocking every other part from rendering.

The solution to that being parallel or async paint/layout, which is something I never hear mentioned (probably because it's a really hard problem).

Servo is actually in the process of implementing a parallel layout engine[1][2]

1: http://en.wikipedia.org/wiki/Servo_(layout_engine) 2: http://pcwalton.github.io/blog/2014/02/25/revamped-parallel-...

Interesting. I wonder how they handle incremental rendering though. Only the forward-path is described in your reference [2].

As far as I can tell there is nothing unusual or difficult here. Servo's incremental layout implementation is here: https://github.com/servo/servo/blob/master/components/layout...

They've recently landed a tool that makes it possible to visualize the parallel rendering: https://github.com/servo/servo/pull/4969

I believe that the Servo project (https://github.com/servo/servo) is attempting to address exactly this.

The proposal only is for sharing memory in between Worker threads, which can't access the DOM (which also means canvas, WebGL, etc aren't able to be accessed). It doesn't do anything to help make UIs smoother: you still have to copy to transfer data from the UI thread to the Worker threads and back. If that isn't a problem, then Workers as-is will unblock your UI: you can already do this with Workers as they're implemented today.

All that this does is make algorithms running inside Workers faster. It doesn't unblock UIs, since Workers already do that if you're willing to accept copying. If copying back and forth from the main UI thread is too slow, this proposal won't change that.

There is active work on allowing WebGL and canvas in workers, with the worker talking directly (not via the main thread) to the compositor.

Re-pasting a link that was buried further down in the discussion. Transferable objects provide zero copy sending/receiving of large amounts of binary data.

https://developer.mozilla.org/en-US/docs/Web/API/Web_Workers...

Reply on news.ycombinator.com