- From: David Sanders via GitHub <sysbot+gh@w3.org>
- Date: Sat, 24 Jun 2017 14:38:41 +0000
- To: public-media-capture-logs@w3.org
@jan-ivar, I'm not worried about people remembering as much as being aware in the first place. In the ideal world where everyone does a deep on the spec before coding then we wouldn't even have to worry about this as a note in the spec would solve it all. :-) Having the spec specify rounding pan and tilt to a fixed 2 decimal places would have the benefit of making it more *naturally discoverable* by users. Where as the float rounding problem would be subtle and hard to debug since it would work fine most of the time, with 2 fixed decimal places the equality check failing would be more obvious to users as the number of decimal places in each would stick out. I still don't love it because again most of the time it would lurk, if developing with a camera that only does 1 degree steps for pan and tilt you'd never notice the issue until someone with a camera that used a non-integer step tried it. > FWIW, aspectRatio is rounded to the 10th decimal point (though nobody implements that constraint yet AFAIK). Good info to have, that there's precedence for rounding to a decimal point with constraints. The main reason it's more prevalent with this spec is `MediaSettingsRange` encourages calculating values with `step` instead of fixed calculations. > I don't know much about arc seconds. AFAIK there's not much to know: an arc-second is 1/3600 of a degree. The applicability here is that none of the underlying OS APIs support less than 1 arc-second granularity so by using arc-seconds you can use integers to represent rotation and avoid the float rounding problem. -- GitHub Notification of comment by dsanders11 Please view or discuss this issue at https://github.com/w3c/mediacapture-image/pull/182#issuecomment-310842355 using your GitHub account
Received on Saturday, 24 June 2017 14:38:47 UTC