In general, when mouse/touch events are generated at a higher rate than the render frequency, the VirtualFlow event handler is doing work that will never lead to a visual change and thus can be avoided.

For example, when you're scrolling on an Android device, you will get about 60 touch input events per second. That leads to 60 calls to VirtualFlow.$$handle. This code will calculate the new cell positions and so on. But in case we can only render at e.g. 30 FPS, it means that we are spending time in calculating positions or cells that will never be shown.

To make it worse, the event handling is done by the JavaFX Application Thread, which means that it has to share its thread with the Rendering, leading to an even lower FPS rate.
The most CPU intensive part of the event handling in VirtualFlow is the adjustPixels(double) method.

With the diff at https://bitbucket.org/javafxports/8u-dev-rt/commits/ff899f6981463cbc795af5bcb1f1fcd0cfc6a210 I move that part to the rendering part. Hence, the expensive calculations are done only once every pulse. The event handling keeps track of the total deltaY and it will request a rendering, and then it is done.