Background

In the message list, if you hit the scroll-to-bottom button, the intended behavior is that it scrolls to the bottom at an average speed of at most 8000 px/sec, the same as the top speed of a fling-scroll, and slower if necessary to make the animation take at least 300 ms.

So e.g. if you've scrolled up by 16000 logical pixels — roughly 20 screenfuls, since 160px has a nominal value of one inch — then the scroll to the bottom will take (16000 px)/(8000 px/sec) = 2 seconds. If you've scrolled up by only 1200 px (roughly 1.5 screenfuls), then the scroll to the bottom will be slower, at 4000 px/sec, in order to stretch it over 300 ms.

Bug

The logic to do that, though — introduced in 5abeb88 (#223) — didn't have any tests. As a result, when an unstated assumption it made got broken a few months later (in bdac26f), nothing alerted us to that. It's been broken since then.

The current behavior is instead that the animation is always set up to take just 300 ms, no matter how far it needs to travel. So for example if you're scrolled 16,000 px up (again ~20 screenfuls), then it will try to go a little over 53,000 px per second, which at 60 fps is 889 px/frame, i.e. likely more than a whole screenful per frame. (And in fact faster than that for part of the time: that's the average over the whole animation, but it uses an easing curve, so it goes faster early on and slower later.)

Scrolling at such ludicrous speed looks very flickery at best, i.e. if the app does successfully render each of those frames on time. It's also quite a strain on performance: the app needs to build, lay out, and render an entire new screenful of messages each frame, and if going by more than a screenful it also builds and lays out all the unseen messages in between in order to know how tall they are. So the actual behavior I usually see is that a lot of frames get dropped, i.e. jank.

Plan

I've spotted this behavior as a user a few times over the past year or so. I don't think we've heard anyone complain about it, though, and I think this button isn't central to the UX, so we haven't prioritized it. But I discovered the cause of the bug while reading the scroll-to-bottom button's code in the course of revising it to work at all in a world of #82, and I'll fix the bug as part of that work.