The split does not remove work. It relocates it. Under one-renderable-per-data-node, the per-frame bill scales with document size because hit-testing, layout and paint all walk objects that are nowhere near the screen [4]. After the split, the bill on each camera transform is a spatial index query against an expanded rectangle plus a diff that keeps what stayed, creates what entered, and unmounts or recycles what left [13]. That trade only pays if the query and the diff stay cheaper than the objects they replace, and the post describes the index as lightweight without saying what it costs to build or to rebuild when the layout changes [9].
The overscan factor is where the tuning happens. A default of 0.5 pads each side by half the viewport's width and height [11], which doubles both dimensions and makes the materialized region four times the visible area [1]. The reason to pay that is pop-in flashing during fast panning [12]. With thousands of live display objects already measured in hundreds of megabytes under the naive model [5], four times the visible area is a real number, not a rounding error.
Edge sampling is the technique that changes what the user sees rather than how fast they see it. Take the post's own example of a hub with 2,000 children [17] and the cap of 32 [15]: the stride comes out at 63 and 32 curves get drawn, roughly 1.6 percent of the fan-out [2]. Part of the justification is legibility, since thousands of overlapping curves read as an undifferentiated blob anyway [16]. Fair enough. But the canvas is now a sample, and anyone eyeballing fan-out is eyeballing that sample. The full graph stays queryable in memory [9], so the true degree is answerable; whether the interface answers it is a separate design decision the post does not reach.
One asymmetry worth naming. The failure is quantified: panning from 60 fps into single digits [6], which is a frame budget moving from about 17 ms to something over 100 ms [3], plus multi-second thrashing on zoom [7] and a scene graph of tens of thousands of objects [19]. The fix is not quantified. Nothing in the material states a frame rate or a memory figure after virtualization [4]. The post also announces four techniques and the text available covers culling, edge sampling, and the opening of the flat-thousands-of-keys case [18]. Read it as an architecture worth copying, from a developer describing his own tool [2], and not as a benchmark.
