True... It’s a difference in complexity between how the data moves between threads and how you reliably use GL off-thread (grumble Intel GMA grumble). Same crazy things crop up when you start to talk about hardware accelerated 2D canvas implementations, too.
Live Labs / Seadragon
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Robert O'Callahan
Sent: Sunday, April 18, 2010 5:24 AM
To: Ben Vanik
Cc: Thatcher Ulrich; Kenneth Russell; public webgl; Chris Marrin; Vladimir Vukicevic
Subject: Re: [Public WebGL] Resurrecting Update Scheduling
Freezing or COW tricks to make pixel buffers cheap to transfer between threads sounds kinda complex to me, and it doesn't even free you from main-thread latency problems, since you still have to get back to the main thread to update the WebGL canvas, and the main thread might be blocked on stuff you don't have much control over.
So if you want to do something with workers, I'd aim high. Create an API that lets you hand control of a canvas over to a worker. Once control has been handed off to the worker, disallow the main thread from making API calls on the canvas again (make them throw), so there are no synchronization issues. You'd still be able to use the canvas as an image source, so the main thread can get snapshots of the canvas state between worker tasks ... that could be useful. Make the worker only get a canvas context, so we don't have to expose DOM elements to workers.
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]