undefined | Better HN

0 pointsnitwit0057y ago0 comments

There's a lot of tricks you can try, but even rendering the first set of visible rows can take more than a 60fps time window will allow.

0 comments

Shog97y ago

Don't pick a fixed value for the batch size; render until your time is exhausted and then wait for the next batch. Yes, this'll be slower overall, but you ensure that the app stays responsive regardless of device or CPU availability.

nitwit005OP7y ago

That seems like it would cause a lot of shifting content as the table gets repeatedly resized due to adding rows.

The only way I see that working out nicely is if you can know the height of the table in advance, which is generally not the case.

writepub7y ago

Are you recommending an app imposed rendering timer (say 15ms) or is there an in built API for Opportunistic scheduling of Dom updates?

ergl7y ago

You might want to check out this thread from last week[0] about scheduling tasks when the event loop is idle. The author also published a library for it[1]

[0]: https://news.ycombinator.com/item?id=18030848

[1]: https://github.com/GoogleChromeLabs/idlize

j / k navigate · click thread line to collapse