Apollo v1.10.0

One change: library and browse grids only render the rows you can see.

Why

A grid pages itself in as you scroll and kept every card. By the bottom of one library that was 12,142 elements and 415 decoded images — and the cost that actually showed on a slow phone was not holding them but making them. Each new page of sixty was built in one go, and the pauses landed exactly there.

What it does

Measured on a phone at a quarter speed, scrolling a screen at a time and pausing to look — how anyone actually reads a library:

	before	after
pauses	2	none
worst pause	181ms	none
elements held	3,585	1,416
images held	120	45

Two visible stutters become none.

Dragged from top to bottom without stopping it is worse — more, smaller interruptions instead of a few large ones. That is a finger on the scrollbar rather than someone reading, and the same run holds 923 elements against 8,804 and 11 MB of memory against 20.

The page stays exactly as tall as it would have been, so the scrollbar does not move under you and coming back to a library still returns to where you were.

What it costs

Find-in-page only matches cards that are rendered, and so does tab order. That is the trade every implementation of this makes, and it cannot be avoided while the point is to not render things. A few rows beyond the viewport in each direction are kept so that arrowing or tabbing past the edge lands on something real.

Verified

1299 tests, 0 lint errors, clean build. In a browser: paging in still works, every sample point down the viewport lands on a card, the hover effect still grows past its box and paints over its neighbour, and going back still returns to the same offset.

Full changelog: v1.9.1...v1.10.0