As part of the continuing crossed-row work, we looked at reducing how much of the chart the engine scans during gameplay.

The idea seemed reasonable. If we know the latest row where something changed, the engine should be able to stop its update there instead of continuing farther through the chart.

StillRiver showed that it was not that simple.

During testing, meaningful gameplay work was still happening beyond the proposed limit. In some cases, the latest changed row was behind the current tap iterator, the mine iterator, or both.

Capping the scan at that point would have saved work, but it would also have skipped behaviour the engine was still expected to process.

Those row paths currently handle more than note positions. They can also advance iterators, apply misses, process mines and hold checkpoints, update combo state, send theme messages and run mode-specific behaviour.

That does not mean all of that work belongs together forever. It does mean we cannot separate it safely by assuming that rows are always processed as one simple forward range.

Warps make this especially awkward. A warp can move the chart position forward without normal song time passing through every row. Fake regions and other timing rules can also contain rows that should not be judged in the usual way. Some game modes and converted charts add further exceptions.

A future row service therefore needs more information than a start row and an end row.

It needs to know how the engine reached that range, whether the rows are judgeable, which gameplay rules are active, and which remaining effects still need to be processed.

The first proposed optimisation did not have enough information to guarantee that, so we did not use it.

That is one of the useful things StillRiver gives us. It does not only show where work can be removed. Sometimes it shows that an apparently obvious shortcut would change gameplay behaviour in ways that are easy to miss.

The current row path still needs untangling, but we now have better evidence about what it is carrying and where the boundaries cannot yet be drawn safely.

A faster scan is only an improvement if it produces the same gameplay result.

This one did not prove that yet.