Re: Bug 23935 - Proposal: New syntax for constraints

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. 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.

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

.: Jan-Ivar :.