- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Sat, 04 Aug 2012 12:24:14 +0300
- To: Florian Bösch <pyalot@gmail.com>
- CC: olli@pettay.fi, Glenn Maynard <glenn@zewt.org>, Scott Graham <scottmg@chromium.org>, Rick Waldron <waldron.rick@gmail.com>, Webapps WG <public-webapps@w3.org>, Ted Mielczarek <ted@mielczarek.org>
On 08/04/2012 12:16 PM, Florian Bösch wrote: > > > On Sat, Aug 4, 2012 at 11:07 AM, bugs@pettay.fi <mailto:bugs@pettay.fi> <bugs@pettay.fi <mailto:bugs@pettay.fi>> wrote: > > The update rate depends on the device. Tablet updates reach way beyond 120HZ and even my 3D mouse clocks in at about 500 events/s. And a major > obstacle for a realtime input device is when the realtime app trying to use it stutters/jitters every quarter second because of 180-250ms > GC-pauses > > > That long GC pauses are bugs in the implementations. File some bugs on all the browser engines you see it (after testing latest nightly builds). > > It doesn't matter if they're bugs (I often see them in conjunction to array buffer allocation). Of course it matters. APIs shouldn't be designed based on implementation bugs > Even at the best of times the GC-pauses are no less > than 90ms, and even if you got it down to 60ms, that's still more than 5 frames @80hz. Until you get GC-pauses down to ~5ms or so, any GC use will > introduce unpleasant stuttering/jittering. And even then it's a close call to not miss a frame. 5ms is quite low when the aim is 60Hz updates... but with incremental/generational GCs 5ms sounds very much possible.
Received on Saturday, 4 August 2012 09:25:17 UTC