-
Notifications
You must be signed in to change notification settings - Fork 6.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
perf(virtual-scroll): use auditTime instead of sampleTime #13131
Conversation
I'll have to take a thorough look at this, I seem to remember intentionally picking |
@mmalerba, I think you're referring to this #10179 (comment) |
Interestingly |
I was wrong.
So in out case the best choice is |
@julianobrasil Thanks, that's what I was thinking of. @nename0 I agree that |
Thanks! |
) The `CdkVirtualScrollViewport` uses `sampleTime` to collect multiple scroll events into one until the next animation frame. However the `sampleTime` also samples even if there is no new upstream values. Which in this case creates an basically useless requestAnimationFrame callback. A better choice would be the `auditTime` operator, which only schedules the requestAnimationFrame when there is actually a new upstream value. In our case it has the exact same behavior, as from looking at the performance profiler in chrome I found out this: first the scroll event fires, then pending requestAnimationFrame callbacks get called, regardless if they where scheduled in the current or previous frame and then the paint occurs.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
The
CdkVirtualScrollViewport
usessampleTime
to collect multiple scroll events into one until the next animation frame.However the
sampleTime
also samples even if there is no new upstream values. Which in this case creates an basically useless requestAnimationFrame callback.A better choice would be the
auditTime
operator, which only schedules the requestAnimationFrame when there is actually a new upstream value.In our case it has the exact same behavior, as from looking at the performance profiler in chrome I found out this: first the scroll event fires, then pending requestAnimationFrame callbacks get called, regardless if they where scheduled in the current or previous frame and then the paint occurs.