Martin Bauer
3cdad1e714
Searching a single letter over a real library puts 340 cards in one grid, each with a cover image, a shadow and a backdrop blur, all of them live whether or not they are on screen. On musicdolphin that saturated the renderer badly enough that a DevTools Runtime.evaluate could not be scheduled on the main thread inside 30 seconds, which is a fair description of what "sluggish" felt like. content-visibility: auto on the grid's cards is the browser's own answer: off-screen cards skip layout, paint and compositing and come back as they scroll near the viewport. The grid's tracks are sized by minmax(180px, 1fr) rather than by card content, so skipping that content cannot move the columns; contain-intrinsic-size supplies the block-axis guess and `auto` remembers each card's real size after its first render, so scroll height and offsetTop - which BrowseView's keep-the-selection- on-screen effect reads - stay honest. Not behind ?pi=1: there is no visual difference to trade away. SHOW_CARD_BLUR separates the repeated frosted surfaces (every card, every list row) from the handful of panels wrapped around them, because the two behave nothing alike and lumping them together is what made the first Pi profile five times slower. A panel is one live backdrop copy that buys its whole subtree a compositing layer; a card is one of three hundred sitting directly over the animated canvas. ?pi=1 now drops the card blur and keeps the panel blur. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>