Yeah the touch event filtering should still be happening, and it occurs on the main thread. If the main thread on the parent process doesn’t respond to the touch event within 1 second from when the kernel notified gecko that a touch event occurred, then we discard the event. We plan to start processing touch events off the main thread in bug 930939, but that is still a whiles away. Another problem is that if the child’s main thread is busy, even though APZ may have already processed the touch event, the child still has to respond to the touch event until we can start scrolling. Like Kyle said though, if we have a lot of zram thrashing and the child is super busy and everything is unresponsive, then filtering touch events won’t help us.
On Sep 14, 2014, at 8:33 AM, Kyle Huey <[email protected]> wrote: > This filtering is only happening at the beginning of the touch event > pipeline. If the delay manifests somewhere else (say the app process > is processing its event queue very slowly) it has no effect. > > - Kyle > > On Fri, Sep 12, 2014 at 11:51 AM, Dietrich Ayala <[email protected]> wrote: >> I was reading the Ars article about Tarako, which mentioned how input events >> would pile up and cause long freezes. >> >> This bug was supposed to mitigate that problem: >> https://bugzilla.mozilla.org/show_bug.cgi?id=971633 >> >> Eric said that change only discards events 1 second old, which might be too >> conservative. >> >> Should we do some testing to see if lowering that would improve the >> situation at all? Maybe we can optimize a little bit more and strike the >> right balance where the user can't input enough events to cause *super* long >> freezes. Just little reasonable freezes :) >> >> >> IRC notes below. >> >> >> 10:01 < dietrich> from Ars: "If you enter too many commands at once, it will >> freeze up for long periods at a time." >> 10:03 < erahm> dietrich: yeah, in theory it discards events after a second >> delay I think. There's some jankiness where we needed to pair key down and >> key up events though >> 10:43 < dietrich> erahm: i wonder if a second is too long >> 10:44 < dietrich> erahm: wdym about the key up/down? >> 10:45 < erahm> dietrich: yeah it was a bit conservative. we need to make >> sure we don't chuck key up events (or touch up whatever) that corresponded >> to key down events >> 10:46 < dietrich> oh gotcha >> 10:48 < erahm> dietrich: something like 125ms is the human threshold for >> detecting jank, so 1s seems too conservative, but given that the tarako is >> inherently slow I think we'd just end up discarding >> way more events than the user would expect. We really need >> some sort of "unresponsive app" notification that kicks in instead >> 10:48 < dietrich> eww >> 10:48 < erahm> that's life w/ zram thrashing :( >> 10:48 < dietrich> or do you mean lower level notification, not UI >> 10:49 < dietrich> discarding more events might be ok though >> 10:49 < dietrich> would really need to test >> 10:50 < erahm> It's should probably be both, it's a better experience to see >> some indication that we're thinking about doing something than tapping a >> bunch and then have apps stutter in and out of >> existence >> 11:00 < dietrich> erahm: what's the original bug #? >> 11:01 < erahm> dietrich: bug 971633 >> 11:01 < freonbot> Bug http://bugzil.la/971633 erahm, RESOLVED, FIXED, --, >> [b2g][tarako] Filter out stale input events >> 11:07 < erahm> dietrich: it would appear that code got moved though, and >> we're probably not filtering touch events anymore >> 11:10 < erahm> dietrich: ah ok, it just got moved over, it should still >> work. Touch filtering is in here: >> http://hg.mozilla.org/mozilla-central/file/935836821a9d/widget/gonk/GeckoTouchDispatcher.cpp >> 11:10 < freonbot> [ mozilla-central: >> widget/gonk/GeckoTouchDispatcher.cpp@935836821a9d ] - hg.mozilla.org >> _______________________________________________ >> dev-b2g mailing list >> [email protected] >> https://lists.mozilla.org/listinfo/dev-b2g
_______________________________________________ dev-b2g mailing list [email protected] https://lists.mozilla.org/listinfo/dev-b2g
