- From: Patrick H. Lauke <redux@splintered.co.uk>
- Date: Sat, 17 Jan 2015 00:03:42 +0000
- To: Jacob Rossi <Jacob.Rossi@microsoft.com>, "public-touchevents@w3.org" <public-touchevents@w3.org>
- CC: input-dev <input-dev@chromium.org>
On 16/01/2015 23:03, Jacob Rossi wrote: > Yet, we don't see a performance hit if mouse events aren't being > listened to. We cache hit-test results from Pointer/Touch events for > use in the mouse events when they are in use (avoiding double > hit-testing). If we added a CSS API for disabling mouse events on a > node by node basis, then you still need to hit-test to determine > which node to retrieve the value of that property...so how does that > help perf? The data structure of a MouseEvent is extremely small and > would be inconsequential memory savings to not have to create. I don't think, at least looking at the thread starter, that this was ever about performance gain, but just about making life easier for devs. > Is there a developer win here* (assuming we also solve the > firedFrom() scenario in another way)? If not, then I think adoption > of some new "don't fire Mouse Events" API would be pretty low. I think the main win (though agree there's much overlap with firedFrom) would be that devs can keep their very mouse-specific handlers untouched (no need to add any extra test for "was this fired as result of a touch, as a compat event?") if they can be safe those handlers won't be called anyway since they explicitly suppress mouse compat. Then again, they'd still need to (in most scenarios) de-dupe click, so this proposed way of suppressing mouse* events can only work hand-in-hand with firedFrom to cover all cases... P -- Patrick H. Lauke www.splintered.co.uk | https://github.com/patrickhlauke http://flickr.com/photos/redux/ | http://redux.deviantart.com twitter: @patrick_h_lauke | skype: patrick_h_lauke
Received on Saturday, 17 January 2015 00:04:09 UTC