Problem
The listCOMP fires onInitCell for every cell on every refresh — regardless of scroll position. A 150-row, 8-column list triggers 1,200 Python callbacks on the main thread per cook. Above ~100-200 rows this causes frame drops and outright crashes, with no way to diagnose it since the overhead is invisible to TD’s profiling tools.
The only workaround is artificially limiting row count at the application level (pagination, forced tree collapse), which degrades UX to compensate for a rendering limitation.
Proposal
Add an opt-in virtualscroll parameter that limits callbacks to rows visible in the viewport (+ a small scroll buffer):
-
onInitCell/onInitRowonly fire for visible rows -
Scrolling triggers callbacks for newly visible rows and releases off-screen ones
-
onInitTable/onInitColunchanged -
numRowsstays accurate for scrollbar sizing
Cost drops from O(total_rows × cols) to O(viewport_rows × cols). A 10,000-row list with 30 visible rows would invoke ~240 callbacks instead of 80,000.
This is standard in every major UI framework (Qt’s QAbstractItemView, WPF’s VirtualizingStackPanel, macOS NSTableView, React react-window).
Related threads
-
Big Bad Lister Part 3 — “Lister is a little slow, with its heavy reliance on Python”