Re: Bug 23935 - Proposal: New syntax for constraints

On 12/12/2013 06:45 PM, Jan-Ivar Bruaroey wrote:
> On 12/8/13 6:28 AM, Harald Alvestrand wrote:
>> On 12/06/2013 07:27 AM, Jan-Ivar Bruaroey wrote:
>>> I spoke too soon. Our proposals are not the same. :-( See below.
>>>
>>> .: Jan-Ivar :.
>>>
>>> On 12/5/13 10:11 AM, Jan-Ivar Bruaroey wrote:
>>>> On 12/4/13 5:13 AM, Harald Alvestrand wrote:
>>>>> On 12/03/2013 10:47 PM, Jan-Ivar Bruaroey wrote:
>>>>>> If expressiveness is a problem, we should address this directly,
>>>>>> which is what I believe my syntax proposal does. I can say:
>>>>>>
>>>>>> [ { width: 4096, height: 2160 },
>>>>>>   { width: 3840, height: 2160 },
>>>>>>   { width: 2880, height: 1800 },
>>>>>>   { width: { min: 1024, max: 4096 }, height: { min: 768, max:
>>>>>> 2160 }, aspect: { min: 1.6, max: 1.9 } ]
>>>>>>
>>>>>> In this example, I prefer certain resolutions I have tested with
>>>>>> (even when higher ones are available), and only if I cannot get
>>>>>> one of those exact ones will I accept a range, but no less than
>>>>>> 1024x768. How would you express that today?
>>>>>
>>>>> Actually, this is ALMOST legal current syntax.
>>>>>
>>>>> { optional: [ { width: 4096, height: 2160 },
>>>>>   { width: 3840, height: 2160 },
>>>>>   { width: 2880, height: 1800 },
>>>>>   { width: { min: 1024, max: 4096 }, height: { min: 768, max: 2160
>>>>> }, aspect: { min: 1.6, max: 1.9 } ]
>>>>> }
>>>
>>> Your example looked so much like mine it threw me. But it will NOT
>>> do what you intended (or at least what was clear in mine), since the
>>> optional algorithm is to try to satisfy ALL non-overconstraining
>>> entries. I.e. a camera that supports both 4096x2160 and 2880x1800
>>> will get selected, but always set to the lower resolution, because
>>> both constraints #0 and #2 will be applied to it.
>>
>> Nope. The camera will be selected, AND its 4096x2160 configuration
>> will be selected. The 2880x1800 configuration is then impossible - no
>> configuration can satisfy both at the same time.
>
> Constraints aren't applied cumulatively AFAIK, so in the current
> algorithm I believe you are wrong here.

Sorry, that's an invalid interpretation of the specification.

>From section 10 (constrainable)

The ordering of optional constraints is significant. In the example in
the previous paragraph, suppose that aspect ratio constraint is
mandatory and that the height and width constraints are optional. If the
height constraint is specified first, then it will be satisfied and the
width constraint will be ignored. Thus the height will be set to 600 and
the the width will be set to 400. On the other hand, if width is
specified before height, the width constraint will be satisfied and the
height constraint will be ignored, resulting in width of 500 and height
of 750.



> It seems to me that a camera that can handle both 4096x2160 and
> 2880x1800 settings will gladly satisfy both constraints, unaware of
> context. It seems to me that to work the way you wanted, cameras would
> need to know that they've already agreed to one setting and refuse
> another setting, which it doesn't have enough context to do, so the
> algorithm would need to be altered to track cameras and what they've
> previously agreed to.

Constraints aren't interpreted by the camera, they're interpreted by the
UA, which is perfectly aware of all the constraints. The UA then makes a
decision on what it asks the camera to do.

Cameras don't have independent intelligence, at least not in this model.


>
> Or we'd go with a syntax like mine that expresses mutual exclusivity
> naturally.

Or we agree on what the current specification specifies, and go with that.

-- 
Surveillance is pervasive. Go Dark.