Viewport.center changes what zero means. Content placed before the centre sliver lays out at negative scroll offset, a behaviour the dev.to post notes is there for chat-style lists that grow upwards [16]. Split the list at the anchor: everything before it in one sliver laid out backwards from zero, the anchor and everything after it in a second sliver marked as the centre [17]. Scroll offset zero is then the anchor, not an estimate of it [17]. CustomScrollView exposes center as public API, and the framework's own chat-style examples rely on the same negative-offset layout [19].
The claim built on that is that jumping to index 842,013 costs what jumping to index 3 costs, because there is nothing above the anchor to measure or build [18]. For it to transfer, the backwards sliver has to be as lazy going up as an ordinary sliver is going down, and your jump has to be acceptable as a rebuild rather than an animation. The published snippet gives a controller, a builder over an itemCount of 1,000,000, and jumpToIndex, with no animated variant [20]. An animation needs a pixel distance between here and there, and the distance to an unbuilt row is exactly the number the list cannot produce [2].
The fixed-extent example shows why nobody wants to own the measured version even when the arithmetic is available. At 72 pixels a row the post puts index 842,013 at offset 60,624,936 [10]. That product is 842,013 x 72; 842,012 x 72 is 60,624,864, and the post's own framing counts 842,012 rows above the target [11][12]. One row of drift in a hand-checked example is the cheapest available argument against computing offsets by hand.
The approaches people reach for first fail for one reason each. Estimate-then-correct visibly hunts, and because the correction lands after paint the user reads the wrong rows first [13]. ensureVisible needs an element, and index 842,013 has none [14]. Building everything is a million elements and render objects with a frame budget measured in seconds, which is what shrinkWrap: true quietly does in some nestings [15]. SliverFixedExtentList is genuinely the fastest option and stops working at the first row that wraps to two lines [10].
On the two dead packages the evidence is uneven. The post is specific about scrollable_positioned_list: it built a second complete list anchored at the target index and cross-faded to it, so for the duration of the transition two full sets of children were alive, laid out and painting, showing up on heavy rows as a flash, a frame drop, sometimes a scrollbar that jumps twice [7][8]. It ties the maintenance burden to that same design, two lists that must agree about scroll position, item extents and which one is authoritative, kept correct across Flutter versions [9]. For scroll_to_index it offers a publish date and nothing else [5]. The million-plus monthly downloads are an aggregate across both, so this source cannot say which package carries the traffic [6].
The anchored version runs one viewport, one set of children, no cross-fade [21]. That removes the state the post says was hard to keep correct [9]. It does not remove the reason two packages existed: Flutter still ships no index jump [3], and jumpTo still wants pixels [1].
