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

I see a few other problems with radius as currently defined.

First, the definition is in terms of screen co-ordinates which means it's
not subject to zooms.  I believe most uses of radius will be to manipulate
something on the page to try to match the contact geometry (eg. for a
painting app).  In this case you actually want units in the page
co-ordinate system.  This is actually how we've implemented radius in blink
(without realizing it wasn't technically what the note defined).  You can
see this, for example, using http://www.rbyers.net/paint.html on a
touchscreen laptop and invoking browser zoom (or by modifying it to permit
pinch-zoom on a mobile device).  PointerEvents also defines their contact
geometry in terms of the page, not the screen.  That said, there's perhaps
also uses for screen-based radius - eg. as input to some gesture detection
library, or to otherwise change UI behavior for small vs. large touches.  I
guess we could specify screenRadiusX/Y and pageRadiusX/Y (this is exactly
analogous to the reasons we need screen, page and client co-ordinates).
 This seems sufficiently niche that it's probably not worth the effort -
I'd be happy just consistently using page-based radius.

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.

Rick


On Thu, May 29, 2014 at 2:22 PM, Rick Byers <rbyers@google.com> wrote:

> I agree this would be a good change - thanks Rob!
>
> In my paint test app (http://www.rbyers.net/paint.html) I handle this by
> considering radius as supported only if I ever see a radius value >1.  This
> breaks down in multi-monitor scenarios.  Eg. if I hook up an external
> touchscreen to my chromebook pixel and touch on the internal display then
> it'll draw circles that match my finger sizes, but if I then move that
> window to the external display all the touch points are tiny because the
> radius reported by the external display is 1.  I'd much prefer to rely on a
> reserved value like 0 to be mean not supported.
>
> The downside is that apps may need to special-case 0, but I'd argue that
> was almost certainly already the case for 1 (a radius of 1 css px is almost
> certainly too small to be a useful radius for any default use case).
>
> I'm guessing there's some history here around the choice of 1 (I probably
> even heard it at one point, but have forgotten).  Perhaps Matt can
> enlighten us.
>
> While we're on the topic, I think radius should also be 'double' instead
> of 'long' - for the same reasons we're changing this in the pointer events
> spec (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25758).
>
> If there's agreement on these points I'd be happy to make an edit to the
> extensions doc and update blink's implementation to match.  In both cases I
> think the risk of compat issues is pretty low (once Chrome 36 hits beta
> I'll have usage stats on it, but I expect it's low and any reasonable
> existing usage should be unaffected by this change).
>
> Rick
>
>
>
> On Thu, May 29, 2014 at 11:35 AM, Robert Flack <flackr@chromium.org>
> wrote:
>
>> I noticed in the touch events extensions spec
>> http://www.w3.org/TR/touch-events-extensions/ that the default radiusX
>> and radiusY is 1 if no value is known.
>>
>> It seems odd to me to use a value that could be legitimately reported by
>> supporting hardware. Would it be reasonable to change the default to 0?
>> This way if users want to they can easily detect and set a sensible
>> application default radius (i.e. var radiusX = event.touches[i].radiusX ||
>> 15;) instead of risking ignoring a real radius of 1.
>>
>> It seems to me like force can already be treated this way as a force of 0
>> doesn't feel like it would legitimately be reported by supporting hardware
>> for an actual touch (assuming a touch always has some pressure).
>>
>> Unless it's common to divide by radius I imagine this wouldn't cause a
>> problem for existing uses of radius.
>>
>> Thanks,
>> Rob
>>
>
>