- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Fri, 31 Aug 2012 16:25:19 -0400
- To: public-webrtc@w3.org
On 8/31/2012 3:55 PM, Martin Thomson wrote: > On 31 August 2012 09:05, Li Li <Li.NJ.Li@huawei.com> wrote: >> So there is a 50ms delay. Would such unbound delay cause any problem in practice or do we have to force the use of worker threads? > I cannot conceive of a WebRTC use case that would depend so heavily on > having a <50ms delay between event and action. Can you? > I can conceive of cases where it would be *highly* preferable to have a <50ms delay between event and action, in particular congestion control feedback (congestion control occurs automatically, but the app gets the chance to override the decisions, so long as it stays within-bounds); and reaction to a remote media change (channel un-mutes, resolution changes, etc); reaction to a datachannel message (games, remote camera control), etc. And I think Li Li's point originally was that the connectivity checks run through JS; even if they work with a >50ms delay, such a delay will slow down call setup. Running those through JS both adds overhead and may potentially add significant delay. And while it's not nice, >50ms delays are quite possible in JS code. If you have very large numbers of tabs in Mozilla or other things forcing very expensive garbage collection (or paging!), pause times can rise over 50ms when a GC or CC occurs (and with paging quite possibly at other points). We have ongoing projects to reduce cases of eventloop delay ("jank", though I hate that term). -- Randell Jesup randell-ietf@jesup.org
Received on Friday, 31 August 2012 20:26:23 UTC