Re: Can we change default radius to 0 in the touch events extensions

On Thu, Jun 5, 2014 at 2:01 PM, Matt Brubeck <mbrubeck@mozilla.com> wrote:

>  On 06/05/2014 10:12 AM, Rick Byers wrote:
>
>  On Thu, Jun 5, 2014 at 12:33 PM, Matt Brubeck <mbrubeck@mozilla.com>
> wrote:
>
>> On 06/05/2014 09:13 AM, Rick Byers wrote:
>>
>>> Secondly, using X and Y for the radius is somewhat limiting.  X11 and
>>> Android instead use an ellipse model of touch contact with touchMajor,
>>> touchMinor and touchRotationAngle.  I've just learned that the Nexus 10
>>> does a really good job of supporting this (you can see it by enabling "show
>>> touch locations" in developer options).  I'm not aware of any device that
>>> returns touch width/height so in practice chrome always reports
>>> radiusX==radiusY.  So I'd prefer we change this to radiusMajor, radiusMinor
>>> and rotationAngle properties.  OSes like Windows 8 that report contact
>>> geometry in terms of width/height can still be properly supported -
>>> rotationAngle would just always be 0, but the inverse is not true.
>>>
>>  Earlier versions of the v2 spec had a "rotationAngle" property that
>> worked like this:
>>
>>
>> https://dvcs.w3.org/hg/webevents/raw-file/c8eccbb92b31/touchevents.html#widl-Touch-rotationAngle
>>
>> It was removed (by accident?) when the document was changed from Touch
>> Events v2 to Touch Events v1 Extensions.
>>
>
>  Yeah I think we removed it because we weren't aware of any
> implementations that used it for anything reasonable (eg. Chrome hard-coded
> it to 0), so didn't want to encourage use of it by websites.  In
> particular, the spec didn't explicitly say how radiusX / radiusY should be
> interpreted when there is a non-zero rotation angle.  Eg. if X11/Android
> returns Major=10, Minor=5, Angle=45deg, then presumably the browser should
> use some math to calculate the distance to the ellipse edge along each axis.
>
>
> No, in the old v2 spec that would simply be equivalent to { radiusY: 10/2,
> radiusX: 5/2, rotationAngle: Math.PI/8 }.  To draw the ellipse described by
> these properties, you start with an ellipse whose axes are parallel to the
> X and Y axes, with the given lengths, *then* you rotate it.  So the math to
> convert to/from Android's PointerCoords is very simple.  I think the
> Android names are definitely clearer, though.
>

Thanks, I see. So the text we had for radiusX/radiusY is a little
misleading: "the radius of the ellipse which most closely circumscribes the
touching area (e.g. finger, stylus) *along the x-axis*".  But the text for
rotationAngle indicates the radius values refer to the pre-rotated ellipse:
"the angle (in degrees) that the ellipse described by radiusX and radiusY
is rotated clockwise about its center;".  Does Mozilla implement this on
any platforms?  If so then I'm fine sticking with the slightly more
confusing names, and I'd support just bringing the old rotationAngle text
back into the extensions note.  Any objection to me doing this (and perhaps
adding some text to clarify the semantics)?

FWIW I've filed http://crbug.com/381394 to track fixing our implementation
in Chrome to match this

What about the "default value of 1" issue that started this thread.  Any
input / history there?

Thanks,
   Rick