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-...
They've recently landed a tool that makes it possible to visualize the parallel rendering: https://github.com/servo/servo/pull/4969
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...
I believe that the Servo project (https://github.com/servo/servo) is attempting to address exactly this.
Re:The Path to Parallel JavaScript
by reissbaker on Thursday February 26, 2015 @06:42PM
(#9116341)
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:The Path to Parallel JavaScript
by shanemhansen on Thursday February 26, 2015 @07:19PM
(#9116479)
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...
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.