I can take this for now at least, to make sure we follow up on it.

I couldn't repro the issue either though.

This is actually one of the smoother infinite scroller implementations I've seen. +flackr@, who is working on an infinite scroller.

Here's attached a trace I've recorded on the Chromebook Pixel:

Google Chrome	53.0.2768.0 (Official Build) dev (64-bit)
Revision	9cd2e77b728d6d5ac115acd944b37df70423c355-refs/heads/master@{#399800}
Platform	8459.0.0 (Official Build) dev-channel link

Deleted: trace_unsplash-scroll-white-flash.json.gz 4.5 MB

trace_unsplash-scroll-white-flash.json.gz 4.5 MB Download

+skyostil, as it looks to me like scheduling changes are making this infinite scroller load content much less aggressively in M53 than M50, which is a bit of a shame.

I don't think the problem is performance related, because this happen even on light pages (I'm the one who originally complained about this behavior to fbeaufort@).

I feel the two finger scrolling logic may be what's causing this.

Are you flinging?
Can you reproduce this on other pages?

> Are you flinging?
The fingers are never leaving the trackpad.
> Can you reproduce this on other pages?
I can reproduce on all the pages.
The original video was made with images because it better shows the jump.

Another point of data:
I've asked 2 other googlers to scroll and tell me what they thought of it, and they both pointed out that it "jumped".

Any suggestions on how to repro this?
Can you repro it in other Chrome versions? M51?

I haven't been able to reproduce this.

+ other scrolling folks.

Also could not repro on 52.0.2743.41 / Original Pixel.

Did you make sure all experimental flags are off?

#5: Are you seeing that from the #4 trace somehow? There don't seem to be many network tasks in that trace that we could be throttling.

FWIW the page seems to be pretty smooth on my Pixel 2. If I fling down very quickly I can reach the bottom of the page before new images come in.

To narrow this down, could you try this on a clean profile that has no experiments/extensions enabled? In particular make sure scroll anchoring is disabled.

Re #11 - sorry! Looks like there's just a bad state that it gets into every once in a while where it takes a long time to load the images. When I was testing before, I got into the bad state a few times in a row on M53, but never saw it in M50. Testing now, they're behaving the same...

Sorry for the noise.

#10> I can reproduce 100% of the time after a power wash with a browser guest session in M51:

Google Inc.
Copyright 2016 Google Inc. All rights reserved.
Google Chrome	51.0.2704.103 (Official Build) (64-bit)
Revision	0
Platform	8172.56.0 (Official Build) stable-channel link
Blink	537.36 (@0)
JavaScript	V8 5.1.281.65
Flash	22.0.0.192-r1
User Agent	Mozilla/5.0 (X11; CrOS x86_64 8172.56.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
Command Line	/opt/google/chrome/chrome --enable-logging --touch-noise-filtering --gpu-sandbox-failures-fatal=yes --ppapi-flash-args=enable_hw_video_decode=1 --ppapi-flash-path=/opt/google/chrome/pepper/libpepflashplayer.so --ppapi-flash-version=22.0.0.192-r1 --touch-calibration=0,0,0,50 --ui-prioritize-in-gpu-process --use-cras --use-gl=egl --user-data-dir=/home/chronos --vmodule=screen_locker=2,webui_screen_locker=2,lock_state_controller=2,webui_login_view=2,power_button_observer=2,*ui/display/chromeos*=1,*ash/display*=1,*ui/ozone*=1,*zygote*=1,*plugin*=2,*chromeos/login/*=1 --default-wallpaper-large=/usr/share/chromeos-assets/wallpaper/default_large.jpg --default-wallpaper-small=/usr/share/chromeos-assets/wallpaper/default_small.jpg --guest-wallpaper-large=/usr/share/chromeos-assets/wallpaper/guest_large.jpg --guest-wallpaper-small=/usr/share/chromeos-assets/wallpaper/guest_small.jpg --login-profile=user --enable-natural-scroll-default --bwsi --homepage=chrome://newtab/ --incognito --log-level=1 --login-user=$guest --login-user=$guest --login-profile=2ea0ef679814b5b5c1489dd406ceee0bd9ca4106 --flag-switches-begin --flag-switches-end --disable-sync --disable-extensions
Executable Path	/opt/google/chrome/chrome


I scroll using two fingers scroll.

Note that I can't reproduce on a pixel 2.

This is a video comparing the scrolling on a pixel 1 (left) and a pixel 2 (right): https://photos.google.com/share/AF1QipPCxqV-ZJ0HPKL5z4mrYy3n7XRXDcQiZK2SVjfm-SPlDvDP6ss5LJeR3mA5ZUQz4g?key=Znh1b1NhYmVHV1hiQmltalNtX1ViWm9xd2tmN2Rn

Is your concern that the Pixel 1 and Macbook show fewer intermediate frames during touchpad scrolling?

adlr@, is there any reason we should expect to see more frames during a touchpad scroll on Pixel 1 than Pixel 2? It looks like on pages where we're able to draw frames at 60fps, we're seeing more intermediate frames for touchpad scrolling on Pixel 2 than Pixel 1.

I think Pixel 1 TP was clocked to 60Hz, but I'm not sure about Pixel 2. In general on Chrome OS, input events are not resampled to 60Hz as they are on android.

When you see a jump, can you file feedback and put "@adlr" along with the description? Then I can look into the logs and help diagnose.

Thanks!

Just filed feedback and mentioned adlr@ in the description.

Over to adlr@.

This seems like a firmware issue we can't fix anymore.

/me Closing this bug then.