- From: David Sanders via GitHub <sysbot+gh@w3.org>
- Date: Mon, 12 Jun 2017 02:27:59 +0000
- To: public-media-capture-logs@w3.org
dsanders11 has just submitted a new pull request for https://github.com/w3c/mediacapture-image: == Add pan and tilt constraints == As promised in issue #177. Only real thing I can think of worth debating is whether to have the setting value be degrees, or arc seconds. They're trivial to convert between, and in UVC it is defined as arc seconds, as well as in more of the Windows APIs. Degrees would be more intuitive for users, but since the underlying API will be returning the `max`/`min`/`step` in arc seconds, the `MediaSettingsRange` may look quite odd if you convert it to degrees, like from `-38.23` to `38.23` with steps of `0.453`. That could also lead to rounding problems in the conversion if the `step` in arc seconds is say 1000, that would be 0.277778 degrees, which is icky to deal with. As long as the camera "snaps" to the nearest valid step the rounding problems matter less, although it's never a great idea to have the value returned be different than the one you just set if the set succeeds. It's unintuitive and could lead to user code failing. Since either setting could be mechanical it may not apply immediately, and any end user code which keeps checking to see if it has changed to the correct value might fail or infinite loop if they set `21.234` degrees and that snaps to `21.2335` or something similar, since a simple `==` check would not be true. @yellowdoge, I'm fairly confident these aren't available in the Android API. Would it make sense to use an `✕` in the implementation status to indicate that feature will never be available? The blank space would indicate that the feature is just not implemented yet, but could be in the future, versus `✕` means it will never be available. See https://github.com/w3c/mediacapture-image/pull/182
Received on Monday, 12 June 2017 02:28:05 UTC