-
Notifications
You must be signed in to change notification settings - Fork 315
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
we should render 1/2 table of items before and after the on-screen rows #25
Comments
We used to do this, but when I changed it reuse the rows I removed it since I figured:
Can you cause issues/stutters/white space when you scroll? Anything specific you're doing (how big is the log, how are you scrolling, etc.?) |
I think there's always going to be a frame or two of latency - unrendered, white rows - as we're populating via javascript, and scrolling dom is likely highly optimized in the browser. I do see what looks like some slight tearing at the top and bottom when I scroll quickly. Some over-rendering above and below would likely take the edge off that? If not a full page above and below, 1/2 page?
I think if we did increase the over-rendering, we'd want to try and re-cycle rows that had already been rendered - i.e., just remove a few rows off the top of the table and add a few on the bottom, and not touch ones that were already present. The tearing on scroll really isn't bad, but we may want to revisit this later to get slightly smoother scrolling. |
I noticed the whitespace today playing around with the tool. Good news is there is an easy fix. The scroll event is sync but using RAF causes us to always miss a frame. There are some clever chrome apis if we cared about 60fps but for us I think all that matters is to general avoid flickering and hit at least 20FPS. Note there were a couple years where scroll was async in chrome which was really annoying for framework authors trying to infinite scroll. |
The table scrolling looks pretty smooth with the latest DevTools. I'm going to close this issue, as it appears fixed. We can re-open if this is still an issue. |
In order to make the virtual table drawing a bit smoother, we should render perhaps 1/2 - 1 full table's worth of contents before and after the visible rows.
The text was updated successfully, but these errors were encountered: