Perché l’animazione 3D allo scroll sembra ferma o al contrario

Tre cose che l’occhio vede quando il passo è troppo lungo

Un’animazione allo scroll è una successione di pose, una per refresh dello schermo. Fra una posa e la successiva l’oggetto ruota di un certo angolo: il passo. Finché il passo è piccolo l’occhio ricostruisce il movimento; quando cresce, succedono tre cose.

• Immagine doppia: se il passo supera la larghezza di un dettaglio, due pose consecutive non si sovrappongono e l’occhio vede due oggetti.
• Rotazione all’indietro: se un dettaglio si ripete ogni P gradi e il passo sta fra metà di P e P, l’occhio sceglie lo spostamento più corto, che è all’indietro.
• Oggetto fermo: se il passo è vicino a P, o a un suo multiplo, ogni posa sembra uguale alla precedente e l’oggetto sembra bloccato.

Un’altra causa dà sintomi simili, il segno della rotazione invertito, ma si riconosce da un indizio: non dipende dalla velocità. L’effetto ruota di carro sì. A scroll lento l’oggetto gira bene; a scroll veloce si blocca o torna indietro.

Il conto: gradi per refresh, non pixel al secondo

Il passo per refresh si calcola con tre numeri: quanti gradi percorre l’oggetto in tutta la corsa, quanto è lunga la corsa in pixel, quanto veloce scorre chi guarda. Gradi per refresh = pixel di scroll per refresh × gradi della corsa ÷ pixel della corsa. I pixel di scroll per refresh sono la velocità divisa per la frequenza dello schermo: 1.500 px/s a 60 Hz fanno 25 pixel.

Sul primo motore del mulinello la corsa era di 1,75 schermate, cioè 1.575 pixel su una finestra alta 900, e il rotore girava di 2,44 gradi a posa su 717 pose. Un limitatore teneva l’animazione sotto i 1.500 pixel di scroll al secondo: a 60 Hz sono 11,4 pose e 27,7 gradi per refresh. Ecco cosa succede alle feritoie, gesto per gesto.

La regola: un quarto del periodo, e un tetto che non dipende dallo schermo

Per leggere il verso della rotazione il passo deve restare sotto la metà del periodo del dettaglio che si ripete; per leggerla con margine, sotto un quarto: è la soglia che abbiamo scelto. Sul mulinello il dettaglio che decide è la gonna del rotore, la fascia con le dieci feritoie, con un periodo di 36 gradi: il tetto è di 9 gradi per refresh.

Il motore in produzione dal 18 settembre 2026 ha due tetti. Il primo è di 240 pose al secondo, contate sulla sequenza completa di 717, e non dipende dalla frequenza dello schermo; il secondo è il passo massimo di 9 gradi per refresh, e vale sempre. A 60 Hz decide il secondo; a 120 Hz basta il primo, che vale 4,9 gradi per refresh.

Il prezzo di questa scelta: dopo un colpo veloce il mulinello non salta alla posa giusta, ci arriva girando alla velocità del tetto. Se ci si ferma dentro la sezione resta una coda di rotazione; fuori scena il recupero è immediato. Oltre 60 pose di ritardo il motore innesta una marcia di recupero 1,6 volte più veloce, sempre sotto i 9 gradi.

Aggiungere fotogrammi non risolve. Passare da 180 a 717 pose, fra l’8 e il 9 agosto 2026, ha reso più piccolo il passo minimo, ma i gradi per refresh dipendono da quanti gradi percorre l’oggetto per ogni pixel di scroll e da quanto veloce scorre chi guarda. Ciò che risolve è il tetto, insieme a una corsa abbastanza lunga: la nostra arriva a 2.214 pixel, meno sugli schermi bassi perché è il minimo fra 2.214 e 2,5 volte l’altezza della finestra, ed è fissata al caricamento della pagina.

Due difetti che si travestono da ruota di carro

La corsa che cambia sotto il dito. Il primo motore accorciava la corsa in base ai fotogrammi già scaricati: il 31 agosto 2026 l’abbiamo vista scendere a 96 pixel, con 5.970 pose al secondo richieste e l’indice che tornava indietro da 716 a 570. La regola che chiude questo difetto: la corsa è un numero solo, deciso al caricamento e mai riscritto mentre si scorre.

La posa sbagliata a cache fredda. Alla prima visita, a cache fredda, il browser non ha ancora le immagini. Quando la posa richiesta non era ancora scaricata, il primo motore mostrava la posa zero: il mulinello tornava all’inizio e si fermava. Oggi il motore mostra solo una posa vicina a quella giusta, entro due pose sul computer e una sul telefono; se non c’è, aspetta. Dopo 4 secondi senza pose lo dice in pagina: il modello sta ancora arrivando.

Decodificare costa poco, se si fa prima di averne bisogno: una posa AVIF (un formato d’immagine compresso) da 900 pixel con canale alfa, cioè con la trasparenza, si decodifica in 2,2 millisecondi su Chromium e in 4-5 su WebKit, misurati il 18 settembre 2026 sul computer di sviluppo, con i dati già in memoria. Il motore decodifica in un worker, codice che il browser esegue in parallelo alla pagina senza bloccarla, e lo fa in anticipo nella direzione in cui il dito sta andando.

Come si misura: la posa letta dai pixel, e un motore da bocciare

Il motore scrive una traccia di ciò che crede di disegnare, ma quella traccia è un righello interno: in una delle prove diceva zero salti mentre i pixel ne mostravano sette. Il banco legge i pixel che il motore disegna davvero: a ogni fotogramma riduce l’immagine del mulinello a una miniatura di 40 × 40 pixel e la riconosce fra le pose vere della sequenza, 717 sul computer e 359 sul telefono. Un salto è un cambio di posa, in un verso o nell’altro, che supera di oltre 1,5 pose il passo massimo per refresh; un passo indietro è una posa che si muove in verso opposto allo scroll, in discesa come in risalita.

Il banco ripete gesti veri, cioè raffica sul trackpad con l’inerzia, rotella a scatti, colpo di pollice e scroll lento, su Chromium e WebKit, con computer e telefono emulati, a cache fredda (su Chromium con la rete limitata a 4 Mbit/s) e a cache calda. Prima di fidarci del risultato lo abbiamo fatto girare sul motore vecchio, che doveva essere bocciato.

Cosa non abbiamo misurato

Domande frequenti

Cos’è l’effetto ruota di carro in un’animazione allo scroll?

È un effetto del campionamento: l’animazione mostra una posa a ogni aggiornamento dello schermo (refresh), non un movimento continuo. Se un dettaglio si ripete ogni tot gradi, come le feritoie di un rotore, e l’animazione avanza a ogni refresh di un passo vicino a quel periodo, l’occhio vede l’oggetto fermo; con un passo fra metà periodo e periodo lo vede girare all’indietro. Dipende dalla velocità: a scroll lento la stessa animazione si legge bene.

Come si risolve un’animazione 3D allo scroll che sembra ferma o gira al contrario?

Si impone un tetto al passo angolare per refresh, pari a un quarto del periodo del dettaglio che si ripete: sul mulinello di DIPANARO, con feritoie ogni 36 gradi, il tetto è di 9 gradi per refresh, e il 18 settembre 2026 il banco di prova ha registrato 20 corse su 20 senza salti. Aggiungere fotogrammi da solo non basta: serve il tetto, insieme a una corsa di scroll abbastanza lunga.

Come si calcola il passo massimo per refresh?

Si prende il periodo del dettaglio visibile che si ripete più spesso e se ne tiene un quarto: sul mulinello le feritoie si ripetono ogni 36 gradi, quindi il tetto è di 9 gradi per refresh. Poi si controlla il gesto più veloce: i gradi per refresh sono i pixel di scroll per refresh moltiplicati per i gradi della corsa, divisi per i pixel della corsa.

Aggiungere fotogrammi risolve il problema?

No. Più fotogrammi rendono più piccolo il passo minimo, ma i gradi per refresh dipendono da quanto ruota l’oggetto per ogni pixel di scroll e da quanto veloce scorre chi guarda. Sul mulinello siamo passati da 180 a 717 pose fra l’8 e il 9 agosto 2026: lo scroll lento è diventato più morbido, ma il blocco a scroll veloce è sparito solo con il motore nuovo, che ha il tetto in gradi.

Vale anche per un modello 3D in tempo reale, in WebGL?

Sì. Qualunque dettaglio che si ripete, come i raggi di una ruota, i denti di un ingranaggio o le pale di una ventola, viene campionato una volta per refresh, che la scena sia calcolata dal vivo o letta da una sequenza. In WebGL la rotazione di ogni fotogramma si controlla direttamente: basta limitare il passo angolare per refresh con la stessa regola.

Come si verifica che un’animazione allo scroll non salti?

Leggendo i pixel disegnati, non la traccia del motore. Il nostro banco riduce ogni fotogramma a una miniatura e la riconosce fra le pose vere, ripetendo gesti di scorrimento veri su Chromium e WebKit, con computer e telefono emulati, a cache fredda e calda. E prima lo si lancia su un motore che sbaglia: se il banco non lo boccia, il banco non sta misurando.