Re: [Bug 25707] New: Make getSettings, getNativeSettings, getCapabilities asynchronous

On 2014-05-15 21:24, Jan-Ivar Bruaroey wrote:
> On 5/15/14 4:45 AM, Stefan Håkansson LK wrote:
>> On 2014-05-15 03:15, Jan-Ivar Bruaroey wrote:
>>> On 5/14/14 8:12 AM, bugzilla@jessica.w3.org wrote:
>>>> There may be situations when getting the data may take some time (e.g. reaching
>>>> out to devices), so we should not stop the main script. (getConstraints should
>>>> be fast)
>>> Can't all this information effectively be gathered during and cached
>>> beyond the originating gUM or applyConstraint call?
>> If that is possible, that would be a really good.
>>
>> But can't the settings vary over time (even with no changes to the
>> constraints)?
>
> Sure, but can they vary over time without involving the UA? if they can,
> then yes, UAs might have to reach out to their device to see how it is
> doing and pull back the latest settings on-demand, which may take time.
> But it seems to me (though I am often wrong) that devices mostly do what
> they're told, so it doesn't seem unreasonable to me to require the UA to
> be able to respond immediately with whatever its current settings are
> without waiting for it to search its pockets.

I'm probably wrong more often than you! But what I have heard is that 
the actual settings can vary over time as a result of CPU resource 
competition, power dissipation nearing the limit etc.

Assume you apply a constraint (required or not) to have a framerate 
between 20 and 40; and then check what is actually delivered. The result 
may be 35. But this may change at any time (I've been told). If the 
framerate constraint was required the app would be notified (and the 
track muted) if it falls outside the range.

If I'm wrong, that would make things simpler - and that would please me.

Received on Friday, 16 May 2014 06:20:39 UTC