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

Stefan,
    In your example, the framerate setting may change at any time. If 
framerate is a mandatory constraint, the UA will have to poll the device 
periodically to check that the setting is within constrained range.  In 
this case, it can cache the value and respond immediately to a request 
for the current setting.  It's true that in the case of an optional 
constraint, the UA doesn't  have to poll to track the value.  However, 
given that the UA will be polling to track the values of properties set 
by mandatory constraints, can't it get all the settings for the device 
at the same time?  Is there an efficiency gain to only polling for some 
of the settings?

- Jim

On 5/16/2014 2:20 AM, Stefan Håkansson LK wrote:
> 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.
>

-- 
Jim Barnett
Genesys

Received on Friday, 16 May 2014 14:23:54 UTC