[webkit-dev] assumption about point packing in multit-touch tests

[Simon Hausmann]

On Wednesday, July 18, 2012 12:53:35 PM ext Benjamin Poulain wrote:
> On Wed, Jul 18, 2012 at 8:59 AM, Tomeu Vizoso <tomeu at tomeuvizoso.net> wrote:
> > Though the W3C spec allows packing more than one touch point update in
> > a single touch event, it says nothing about how these updates should
> > be packed, so I think that the current tests are too restrictive and
> > should be relaxed to stop assuming anything about how the updates are
> > packed into events.
> 
> In practice, every port does the exact same thing for the delivery of
> touch events. It is also what the Web content expects nowadays.

I think it would be better if it were _allowed_ if the platform delivered 
multiple touch events for individual touch point updates. I mean in some way 
it is in fact up to the user to the extend that if my mind wants to move two 
fingers simultaenously it might just happen that one finger moves first and only 
a few milliseconds later the second finger starts moving.

Nevertheless I agree that the tests are good that way because they do require 
the platform to at least _support_ multiple updates in one event.

On a low level that requirement is satisfied by Cocoa touch events, WM_TOUCH on 
Windows and even the Linux kernel supports it, from the kernel protocol up to 
protocols like wayland with a specific touch_frame event to indicate the end of 
a contact point list update with multiple points. It seems it's only XInput 
that stands out, and Qt for example covers it up again by just remembering the 
state of the other touch points. But since there is no notion that indicates 
the end of an multi point touch update, we end up with multiple touch events.

> It looks like this spec needs an update, not the WebKit tests.

I don't think the spec should be changed so that XInput based platforms cannot 
satisfy the spec requirements. But I agree that the tests are good the way 
they are because they enforce the requirement to at least possibly support 
multiple updates in one event.

Another argument for keeping the current behaviour in the tests is that the 
JavaScript API (initTouchEvent) takes a touch _list_, and theoretically JS 
could send a (synthetic) touch even that way. It would be wrong to split that 
event up into multiple events with one per changed touch point. So I think 
it's only fair to require the platform to at least support the same semantics.


Simon