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

Re: GamepadObserver (ie. MutationObserver + Gamepad)

From: Olli Pettay <Olli.Pettay@helsinki.fi>
Date: Sat, 04 Aug 2012 12:24:14 +0300
Message-ID: <501CEA3E.4080401@helsinki.fi>
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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:37 UTC