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
