We can't use click as is because preventDefault on touchevents will prevent the click, and we need to call preventDefault to receive events on safari. Also, click on touch does not have the "sloppy cursor" mechanics as it does on mouse, where the deepest common ancestor of the mousedown and mouseup determine where the click is sent.
On Wed, Jul 16, 2014 at 9:03 AM, Rick Byers <[email protected]> wrote: > Yeah I don't think there's really a perf argument here. The overhead of > eager GR should be trivial. > > Back to Tom's original question about detecting 'tap' in a way consistent > with the platform: we do effectively expose this gesture to the web page - > via the "click" event. Note that this currently takes things into account > (does touch adjustment, uses device-specific slop values, etc.) which can't > be done well from JavaScript today. So we generally encourage people to > use 'click' rather than do their own gesture detection for tap. > > There are some scenarios where this is inconvenient though, but we've got > some ideas for how to fix that - it's just not clear to me what's important > enough to prioritize. Daniel, what are the scenarios where your "tap" > gesture is better than relying on the browser's click event? > > Rick > > On Wed, Jul 16, 2014 at 11:37 AM, Jared Duke <[email protected]> wrote: > >> We've worked hard to keep browser-side gesture detection costs down (~60 >> microseconds CPU time per event across a given touch scroll on a Nexus 4). >> There may be some clever tricks we can do to cut this down further, e.g, >> if we see that Javascript has preventDefault'ed the initial touchstart we >> can early out from detection for that sequence (modulo some async nuances). >> The advantages in doing eager/greedy gesture detection have so far >> outweighed the potentially redundant cost. >> >> Longer term, there may be advantages to hosting the (native) gesture >> detector in the render process where communication with JS is cheaper and >> tighter. >> >> >> >> >> On Wed, Jul 16, 2014 at 5:49 AM, Timothy Dresser <[email protected]> >> wrote: >> >>> With eager gesture detection, the browser gesture detector will run on >>> all touches, which means that when a JS gesture detection library is >>> running, gesture detection is happening twice. >>> >>> There are two problems here: >>> 1. JS gesture detection feels different from native gesture detection >>> 2. Doing gesture detection twice may cause performance issues. >>> >>> The first problem could be solved for Chrome by releasing a JS version >>> of Chrome's gesture detector (emscripten anyone?). Perhaps the community >>> would also create versions which match the behavior of other browsers' >>> gesture detectors. >>> >>> We could solve both problems by dispatching some event to JS for each >>> gesture that the browser detects, but I think there are a lot of >>> non-technical hurdles here. Trying to expose the notion of "gestures" >>> through web standards would be... difficult to navigate. +rbyers, as he's >>> more familiar with why this would be hard. >>> >>> Tom, do you have any data on much of a performance problem JS gesture >>> detection is? >>> >>> >>> >>> On Tue, Jul 15, 2014 at 11:27 PM, 'Zeeshan Qureshi' via input-dev < >>> [email protected]> wrote: >>> >>>> Yes, and with eager gr we might already be processing the event stream >>>> in parallel waiting for the ack. >>>> On Jul 15, 2014 11:25 PM, "Tom Wiltzius" <[email protected]> >>>> wrote: >>>> >>>>> >>>>> >>>>> >>>>> On Wed, Jul 16, 2014 at 12:19 PM, Zeeshan Qureshi <[email protected] >>>>> > wrote: >>>>> >>>>>> Folks on input-dev can correct my understanding if its wrong, but >>>>>>> there's already a first-class notion of a "tap" gesture in Chrome. I >>>>>>> don't >>>>>>> think we expose it, but it's there (eating up resources), so it would be >>>>>>> really nice to take advantage of it. There's also a gesture recognizer >>>>>>> in >>>>>>> the browser that decides whether you're e.g. scrolling vs tapping. It >>>>>>> seems >>>>>>> a real shame to have this logic running every time the user touches the >>>>>>> screen, only to have all of that logic re-done (potentially with slight >>>>>>> differences in behavior) in JS. >>>>>>> >>>>>> >>>>>> I don't think the logic is run twice, Tim can correct me if I'm >>>>>> wrong. If there is a touch handler, the touch events are dispatched to >>>>>> blink which can be consumed and prevent defaulted. Only if they are not >>>>>> prevent defaulted are they fed into the gesture recognizer to generate >>>>>> Gesture* events and then dispatched to blink. >>>>>> >>>>>> Any library that wants to have their own gesture detector would start >>>>>> consuming them at the touch events level and prevent default them. >>>>>> >>>>> >>>>> It can't quite be that neat, though, because you can still get >>>>> scrolling with touch event handlers. So a JS gesture library would >>>>> intercept all touch events and at some point early in a touch stream >>>>> decide >>>>> that this wasn't a gesture it was interested in. At that point, the >>>>> browser >>>>> would have to look at the touch event stream and decide that this *was >>>>> *worth scrolling. The conclusions are different, but the logic must >>>>> be nearly the same... >>>>> >>>>> >>>>> >>> >> > Follow Polymer on Google+: plus.google.com/107187849809354688692 --- You received this message because you are subscribed to the Google Groups "Polymer" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAAUAVAi4-9TkobRYYK5kiuy%3DOqCvx%2Bp8H-DVB34MByUhz6iaZQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
