We have quite a few angle fields in internal event plumbing layers, to represent contact surface orientation (2D) & pen orientation (3D).  These were added & modified incrementally over a long period of time, and in a pretty inconsistent state in terms of their definitions.

For example, for contact surface orientation angle, we have duplicate fields at the ui level:
- ui::TouchEvent::rotation_angle_ --- follows the MotionEvent spec.
- ui::PointerDetails::twist --- follows the PointerEvent spec.
- And none of them follows the TouchEvent spec, at least as far as I
can recall from the comments.

This is confusing for code changes.  Moreover, we sometimes go through redundant angle conversions in the event path.  We recently fixed some of the Android angles to follow PointerEvent spec here: https://codereview.chromium.org/2860793003/

This is non-trivial to fix because the definitions involve different
ranges and "base vectors" for angle measurement.  We have to be careful at every edge cases.

We should move all internal angle plumbing to the PointerEvent spec
since this is the most expressive one (see the CL above for a quick explanation).
 

We have quite a few angle fields in internal event plumbing layers, to represent contact surface orientation (2D) & pen orientation (3D).  These were added & modified incrementally over a long period of time, and in a pretty inconsistent state in terms of their definitions.

For example, for contact surface orientation angle, we have duplicate fields at the ui level:
- ui::TouchEvent::rotation_angle_ --- follows the MotionEvent spec.
- ui::PointerDetails::twist --- follows the PointerEvent spec.
- And none of them follows the TouchEvent spec, at least as far as I can recall from the comments.

This is confusing for code changes.  Moreover, we sometimes go through redundant angle conversions in the event path.  We recently fixed some of the Android angles to follow PointerEvent spec here: https://codereview.chromium.org/2860793003/

This is non-trivial to fix because the definitions involve different ranges and "base vectors" for angle measurement.  We have to be careful at every edge case.

We should move all internal angle plumbing to the PointerEvent spec
since this is the most expressive one (see the CL above for a quick explanation).