192 prove desktop su Three.js, il post-processing pesa sulle draw call

Il 28 ottobre 2026 Alicia ha pubblicato 192 prove desktop su tre scene Three.js, eseguite con caricamento della pagina da zero, per misurare l’impatto del post-processing oltre il contatore degli FPS¹. Con gli effetti attivi, il browser restava spesso intorno a 60 fotogrammi al secondo. Il carico di rendering però cambiava¹.

Le prove hanno coperto N8AO, bloom, tone mapping, volumetric beams, reflections e la risoluzione del render-buffer¹. Ogni run partiva da una pagina fresca¹. Le misure sono riproducibili e servono per ispezionare uno stack. Non sono una tabella universale di millisecondi da sommare a qualsiasi scena¹.

Il risultato più utile è arrivato da un controllo negativo. Su Reliquary, impostare il bloom a intensità zero ha prodotto esattamente la stessa immagine ottenuta rimuovendo il bloom. La differenza stava sotto il cofano: restavano 16 draw call in più¹. L’immagine coincideva, il lavoro no¹.

I tempi hanno portato anche un avviso. Ripetere le esecuzioni su desktop, in alcuni casi, ha introdotto variazioni maggiori del piccolo effetto che si stava cercando di misurare¹. L’articolo mantiene visibili questi intervalli, invece di ridurli a un unico numero¹. Il messaggio è chiaro: i range contano quanto il valore centrale quando l’effetto è piccolo¹.

Il punto di partenza è stato Dioramas, fissato al commit 868539f¹. Alicia ha adattato le pagine Reliquary e Kōen¹. Le scene servono per misurare in modo controllato gli effetti e i parametri citati, non per derivare un valore valido ovunque¹.

Accendere il post-processing non lasciava invariato il lavoro di rendering, anche quando il contatore degli FPS restava stabile intorno a 60¹. La differenza si osserva nelle metriche raccolte durante le prove. L’articolo documenta cosa cambia e come verificarlo, con misure ripetibili su pagina fresca¹.

La disclosure è esplicita. Codex ha implementato il harness, eseguito e controllato gli esperimenti, analizzato le ricevute e assistito la scrittura¹. Le misure sono datate, su desktop, con limiti dichiarati¹. L’obiettivo è offrire ricevute sperimentali e un modo per ispezionare lo stack, non un listino di costi da applicare ad altre scene¹.

Il lavoro copre tre scene, 192 run, e una serie di effetti spesso usati insieme. Include un controllo negativo che isola una differenza tra immagine e costo, e mette in mostra la variabilità tra run¹. L’autrice misura e pubblica nella stessa data, 28 ottobre 2026¹. Chi legge trova i range, non solo i valori medi, e una lista di impostazioni toccate nelle prove¹.

Originally published by Alicia on 28 October 2026: Digital Garden. L’articolo propone misure riproducibili e un percorso per ispezionare uno stack, al posto di una tabella unica di millisecondi da aggiungere a qualsiasi scena¹.