Re: [Bug 23820] New: Add special values for PropertyValueRange to enable preference specification in optional constraints

On 20/11/13 18:27, Martin Thomson wrote:
> On 20 November 2013 08:17, Jan-Ivar Bruaroey <jib@mozilla.com> wrote:
>> Shouldn't we first nail down what min and max mean? e.g.
>
> This I agree with.  But the answer might not be as deterministic as
> you might like.
>
>> - Does { mandatory: { width: { min: 1024 } } } conservatively give me
>> 1024x768
>>    or the highest available because I didn't constrain upward?
>>
>> - Does { mandatory: { width: { max: 2880 } } } aggressively give me
>> 2880x1800
>>    or the lowest available because I didn't constrain downward?
>>
>> - Given choices, what does { mandatory: { width: { min: 1024, max: 2880 } }
>> } give me?

I'm going to throw in one more thing here (relevant only to 
width/height/aspect): how do we relate this to the width and height of 
the consumer?

Say a video MediaStreamTrack with mandatory setting of width min 1024 is 
only attached to a video element with a width of 200. Should the camera 
really produce a stream with width 1024, only to have it scaled at 
display time?

>
> The answer to these is universally, "I don't know".  And I think that
> I am perfectly comfortable with that.
>
>> I think we need to establish default behavior of the algorithm here (please
>> point me to it if this is already done).
>
> I disagree.  Obviously, we would like to have a situation where the
> "best" source is selected, but that is a multi-dimensional
> optimization problem that the browser is required to manage.  Then
> there is user preference thrown in.
>
> When you get down to it, constraints on selection are just additional
> input into the selection algorithm that the browser chooses to
> implement.
>
> Given that, I think that it would be folly to specify an algorithm to
> the extent that different browsers produce identical results for all
> variations of constraints and sources.  There's a place for
> standardization, but I don't think that this is it.
>
> I don't think that having additional preferences is necessary.  That
> is the function that optional constraints fulfill already.  Having
> more ways to influence the selection algorithm is only going to make
> it harder to build and understand.  I worry that we are already in
> that situation; let's not make it worse.
>
> (Actually, I do like the "prefer" suggestion.  But it's duplicative,
> so I'd be interested only if you also remove optional constraints at
> the same time.  I consider that to be an unlikely outcome at this
> stage.)
>
>

Received on Wednesday, 20 November 2013 17:42:00 UTC