Re: [Bug 26526] Fix aspect ratio constraint

Incidentally: if we go with an epsilon, we now have to discuss how big we
make it. 0.1? Less? More? How do we know that in the future there may not
suddenly be a need for a more subtly different aspect ratio? We could go
with a string of "x/y" if you prefer just having a single value.

Best Regards,
Silvia.
On 11 Aug 2014 07:48, "Silvia Pfeiffer" <silviapfeiffer1@gmail.com> wrote:

> What's the difference between providing a float to give the aspect ratio
> and a float to provide an epsilon for accuracy to providing two integers to
> provide exact aspect ratio? It's two numbers either way. Actually, two
> integers need less storage, are easier to understand and read by users (you
> could have fooled me with expecting to know that 1.7 is supposed to be
> 16/9), and more accurate. I really don't see where you see the advantage?
>
> Best Regards,
> Silvia.
> On 11 Aug 2014 03:05, "Jan-Ivar Bruaroey" <jib@mozilla.com> wrote:
>
>>  On 8/9/14 6:06 PM, Eric Rescorla wrote:
>>
>> With AspectRatio, the problem
>>  is that the user wants to specify a ratio that can't be accurately
>> represented
>> with a double and we've just defined a language that's too impoverished
>> to represent that.
>>
>>
>> Realistically, are there going to be competing standard aspect ratios
>> within epsilon?
>>
>> For hardware that can do flexible ratios, is double-precision
>> insufficient to deduce the other pixel dimension?
>>
>> If not, then I think this is largely a problem that implementations
>> should solve without affecting users. Users specifying 1.78, 1.77777777778
>> or 16/9 presumably all mean exactly the same thing, the standard 16:9
>> widescreen aspect. Thus an epsilon seems reasonable to me for aspectRatio,
>> and introducing fractions seems overkill from a user's perspective.
>>
>> .: Jan-Ivar :.
>>
>>