- From: Glenn Maynard <glenn@zewt.org>
- Date: Fri, 8 Mar 2013 08:42:19 -0600
- To: David Rajchenbach-Teller <dteller@mozilla.com>
- Cc: whatwg@whatwg.org, Tobie Langel <tobie.langel@gmail.com>
On Fri, Mar 8, 2013 at 4:51 AM, David Rajchenbach-Teller < dteller@mozilla.com> wrote: > a. saving the state of the current region in an open world RPG; > b. saving the state of an ongoing physics simulation; > These should live in a worker in the first place. c. saving the state of the browser itself in case of crash/power loss > (that's assuming a FirefoxOS-style browser implemented as a web > application); > I don't understand this case. Why would you implement a browser in a browser? That sounds like a weird novelty app, not a real use case. Can you explain this for people who don't know what "FirefoxOS" means? d. backing up state and history of the browser itself to a server > (again, assuming that the browser is a web application). > (This sounds identical to C.) Similarly, for a 3d game, until workers can perform some off-screen > WebGL, I suspect that a considerable amount of complex game data needs > to reside on the main thread, because sending the appropriate subsets > from a worker to the main thread on demand might not be reactive enough > for 60 fps. I have no experience with such complex games, though, so my > intuition could be wrong. > If so, we should be fixing the problems preventing workers from being used fully, not to add workarounds to help people do computationally-expensive work in the UI thread. -- Glenn Maynard
Received on Friday, 8 March 2013 14:42:45 UTC