La fluidità di Chrome su Android non è mai stata solo una questione di potenza del processore o di schermi con refresh altissimo. Basta un evento tattile che arriva con qualche millisecondo di ritardo, un thread rimasto occupato più del previsto o un messaggio tra processi che deve fare troppi passaggi, ed ecco che la pagina sembra incepparsi proprio sotto il dito. Google sostiene di aver ridotto del 48% la frequenza degli scorrimenti irregolari, lavorando su tutto il percorso che collega il touchscreen alla comparsa vera e propria dei pixel a schermo.
Il fenomeno ha un nome preciso, scroll jank. Durante lo scorrimento, uno o più fotogrammi non riflettono in tempo la nuova posizione della pagina. Lo schermo ripropone quindi per un ciclo il contenuto precedente, generando quel piccolo scatto che l’occhio coglie immediatamente, soprattutto sui telefoni con pannelli ad alta frequenza. I margini sono strettissimi. Un display a 60 Hz aggiorna l’immagine ogni 16,7 millisecondi, a 90 Hz si scende a circa 11,1 millisecondi, mentre a 120 Hz restano appena 8,3 millisecondi. Dentro quella finestra il browser deve ricevere il movimento del dito, capire quale elemento stia scorrendo, calcolare la nuova posizione, comporre il fotogramma e consegnarlo ad Android. Essere veloci in media non basta. Conta soprattutto evitare gli intoppi improvvisi.
Perché lo scorrimento del browser è più complicato di quello di un’app
Un’applicazione Android qualsiasi può ricevere sullo stesso thread sia gli eventi di input sia il segnale VSync, cioè il riferimento temporale che segna l’inizio di un nuovo ciclo di aggiornamento. Il percorso è corto e lineare. Chrome invece lavora diversamente, perché divide le attività su più processi per contenere i crash, isolare i siti e ridurre i rischi di sicurezza. Il browser process gestisce interfaccia e schede, i renderer elaborano HTML, CSS e JavaScript, il processo GPU si occupa della composizione grafica. Un’architettura solida, ma che rende più difficile mantenere tempi uniformi.
Una delle novità principali si chiama Input Vizard. Storicamente Android consegnava gli input al thread principale, che però nel caso di Chrome è già affollatissimo tra interfaccia, navigazione e messaggi da altri processi. Un compito lungo poteva trattenere persino il movimento del dito. Ora, grazie a un lavoro condiviso con il team Android, Chrome può ricevere input e segnali VSync direttamente sul thread del compositore Viz nel processo GPU. Il main thread esce così dal percorso critico dello scorrimento. Il guadagno non sta nel rendere ogni operazione più rapida, ma nell’eliminare una fonte di ritardi imprevedibili.
Predizione del movimento e barra che non frena più
Per rendere lo scorrimento più regolare entra in gioco l’Input Framer, che attende un evento tattile arrivato in ritardo fino a circa un terzo del ciclo, quindi circa 5,6 millisecondi a 60 Hz e 2,8 millisecondi a 120 Hz. Se il campione non arriva in tempo, il browser stima la posizione successiva sulla base dei movimenti precedenti. A ridurre ulteriormente i ritardi ci pensa Direct2Thread, che permette ad alcuni messaggi critici di raggiungere direttamente il thread destinatario senza passaggi intermedi. Non è un’accelerazione spettacolare, ma dà tempi più regolari, e a 120 Hz anche una piccola deviazione basta a produrre uno scatto visibile.
C’è poi la questione della barra superiore. Quando si scorre verso il basso i controlli del browser si ritirano per lasciare spazio al sito, ma pagina e barra appartengono a superfici diverse e devono muoversi in sincrono. La soluzione chiamata Browser controls in Viz sposta questo coordinamento nel processo GPU, così barra e contenuto continuano a muoversi insieme anche quando il thread principale è impegnato.
Il 48% dichiarato va comunque letto con calma. Descrive la variazione nella frequenza degli scorrimenti classificati come irregolari, non significa che ogni pagina scorra il 48% più veloce né che i fotogrammi al secondo siano cresciuti nella stessa misura. I benefici dipendono dal dispositivo, dalla versione di Android, dalla frequenza del display e dal carico della pagina. Alcune modifiche richiedono la collaborazione del sistema operativo, quindi su versioni molto vecchie l’effetto potrebbe non essere lo stesso. E un sito può ancora rovinare tutto con JavaScript eseguito troppo a lungo, listener touch non passivi, layout modificati di continuo, effetti CSS pesanti o immagini sovradimensionate.