Re: [webkit-dev] assumption about point packing in multit-touch tests
On Wed, Jul 18, 2012 at 9:53 PM, Benjamin Poulain benja...@webkit.org wrote: On Wed, Jul 18, 2012 at 8:59 AM, Tomeu Vizoso to...@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. It looks like this spec needs an update, not the WebKit tests. Could you please elaborate on how the spec would be updated? Thanks, Tomeu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] assumption about point packing in multit-touch tests
On Wednesday, July 18, 2012 12:53:35 PM ext Benjamin Poulain wrote: On Wed, Jul 18, 2012 at 8:59 AM, Tomeu Vizoso to...@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 ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] assumption about point packing in multit-touch tests
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. It is not unusual to have a provision for implementation details like XInput. Describing how it is supposed to work help making implementations more consistent. Anyway, this should be discussed on the W3C list, not this list. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
[webkit-dev] assumption about point packing in multit-touch tests
Hello, I'm working in adding support for the Touch Events W3C API to the Clutter port (and plan to do the same for the Gtk+ one afterwards) and I'm finding a problem when running the tests because they assume that the underlying platform allows packing touch point updates within single touch events. Clutter (and Gtk+, for that matter) provide thin APIs on top of XInput's which does no packing at all: each touch point update is a touch event. Tests such as basic-multi-touch-events-limited.js assume that the platform is able to emit touch events that contain more than one touch point update and also that WebCore will get the same grouping of touch points, but that's not true in XInput-based platforms. 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. I would change the tests to check that after generating a series of touch point updates, the web page has received each of those touch point updates, but not check anything about how they were packed in touch events. Does it make sense to everybody? Thanks, Tomeu ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
Re: [webkit-dev] assumption about point packing in multit-touch tests
On Wed, Jul 18, 2012 at 8:59 AM, Tomeu Vizoso to...@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. It looks like this spec needs an update, not the WebKit tests. Benjamin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev
