So, there is a cheap way to communicate between the DOM thread and web worker threads. It's called Transferable Objects. The technique involves postMessage()'ing a Typed Array's ArrayBuffer as your message payload. Rather than making a copy of the bytes in your sending thread's Typed Array, the byte buffer is "detached" from the sender's ArrayBuffer and "attached" to a new ArrayBuffer on the receiver thread. This allows you to do huge bulk operations on a worker thread, generating megabytes of data for the DOM thread and not taking a penalty of allocating memory, copying the data, and garbage collecting a big allocation on the sender thread.
Transferable Objects are not as useful as, say, being able to access the DOM from a worker thread. But there are many tasks that ultimately feed DOM updates, are data intensive, and could be mostly offloaded to a worker thread with the final update payload fed to the DOM thread via Transferable Objects.
The DOM/Layout/CSS is a crufty document engine. Is it reasonable with today's hardware to have a 60Hz scroll rate benchmark of quality? I think expanding mobile main memories and CPU advances this decade will make it more reasonable.
How about framelocking us to 30Hz on mobile, could we be satisfied with that? Makes me wonder if there is a way to framelock a browser scroll with requestAnimationFrame().
The problem with Transferable Objects is that they only work for raw buffers. This is great for math intensive tasks such as image processing, but not that great for UI related tasks.
We want to be able to share js objects, arrays and strings in a fast way. Otherwise you either need to build your entire app on-top of raw buffer but that doesn't look like JS anymore, or you've got to do a serialization step and you're not gaining much compared to JSON serialization.
I'm super excited about immutability because it lets us share objects between different threads very cheaply and still letting us use normal js constructs. I'm not sure anyone is working on it though :(
Transferable Objects are not as useful as, say, being able to access the DOM from a worker thread. But there are many tasks that ultimately feed DOM updates, are data intensive, and could be mostly offloaded to a worker thread with the final update payload fed to the DOM thread via Transferable Objects.
http://updates.html5rocks.com/2011/12/Transferable-Objects-L...
The DOM/Layout/CSS is a crufty document engine. Is it reasonable with today's hardware to have a 60Hz scroll rate benchmark of quality? I think expanding mobile main memories and CPU advances this decade will make it more reasonable.
How about framelocking us to 30Hz on mobile, could we be satisfied with that? Makes me wonder if there is a way to framelock a browser scroll with requestAnimationFrame().
-- edits clarifying ArrayBuffer