W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

[Bug 17415] (JSWorkers): JavaScriptAudioNode processing in workers

From: <bugzilla@jessica.w3.org>
Date: Mon, 09 Jul 2012 02:36:50 +0000
Message-Id: <E1So3qE-0001Fr-UY@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17415

--- Comment #36 from Grant Galitz <grantgalitz@gmail.com> 2012-07-09 02:36:50 UTC ---
An even bigger blocker for me actually is the keyboard events. I cooked up a
webworker based version of JS GBC long ago and noticed at the time that I had
to pass keyboard event notifications to the webworker, causing one to
experience lag with input as well. It's the being forced to pipe so much from
the UI to the worker that makes webworker usage for my case entirely pointless
at the moment. A webworker is going to need access to almost as many APIs as
the main thread if we're going to perform real time processing with low latency
that involves various forms of dynamic input. Adding thousands of lines of code
to make a single-threaded application perform worse in a web worker versus the
UI thread seems silly to me.

Also the UI thread being blocked from other tabs is experienced on a
per-browser basis for me at least, with Chrome in the clear actually. I do
experience things like js timers dropping from 4 ms to 500 ms intervals when I
do things like try to hover over the mac os x dock or change the volume, so
forcing multi-tasking within the js environment via workers seems like the
"fix" for firefox at least.

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Monday, 9 July 2012 02:36:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 9 July 2012 02:36:52 GMT