CPU Rendering: cos’è, principi e come funziona il rendering software

Cos’è CPU Rendering?

CPU Rendering è un metodo di formazione dell’immagine in cui tutte le fasi della pipeline grafica vengono eseguite sul processore centrale tramite calcoli matematici. A differenza della GPU, dove rasterizzazione e texturing sono integrati in blocchi specializzati, la CPU li esegue tramite istruzioni universali SSE/NEON.

Storicamente, tutto il rendering era software — le prime interfacce grafiche (Xerox Alto, 1973) e i giochi 3D (Quake, 1996) venivano renderizzati sulla CPU. Il termine “software renderer” è diventato sinonimo di CPU Rendering. La transizione all’accelerazione hardware è iniziata con l’avvento di acceleratori 3D accessibili alla fine degli anni ’90, ma il rendering software è rimasto come meccanismo di fallback.

Secondo Akamai (2025), CPU Rendering viene utilizzato nel 35% delle sessioni web mobili come modalità di rendering principale — su dispositivi deboli, in emulatori e quando l’accelerazione GPU è disattivata. Sulle piattaforme iOS e Android, i framework UI (UIKit, Android View) renderizzano sempre i primi fotogrammi sulla CPU prima di inizializzare i comandi GPU.

I processori moderni supportano istruzioni SIMD (SSE4.2, AVX-512, ARM NEON), che imitano parzialmente il parallelismo della GPU. Tuttavia, il numero fisico di core (4–12) e la mancanza di blocchi specializzati di rasterizzazione limitano le prestazioni di CPU Rendering su grafica complessa.

Fasi del rendering software

La pipeline software include le stesse fasi di quella hardware: trasformazione dei vertici, clipping, rasterizzazione, texturing e output dei pixel. La differenza è che ogni fase è implementata software tramite codice C++ o assembly, anziché tramite blocchi GPU fissi.

La trasformazione dei vertici in CPU Rendering viene eseguita tramite moltiplicazione di matrici — 4x4 per proiezione e modellazione. Con 10.000 poligoni, si tratta di 40.000 moltiplicazioni vettoriali per fotogramma — un carico che la CPU gestisce in 5–10 ms con codice ottimizzato. La rasterizzazione è la fase più pesante, che richiede il calcolo della copertura dei pixel per ogni triangolo.

Nei processori mobili, ARM NEON accelera il rendering software tramite istruzioni vettoriali a 128 bit. Secondo ARM (2025), un software renderer ottimizzato NEON funziona 3–4 volte più veloce di un’implementazione scalare su Cortex-X4 alla stessa frequenza di clock.

Come funziona il rendering software?

Il rendering software inizia con la preparazione della scena sulla CPU: la geometria (vertici, poligoni) viene trasformata dalle coordinate mondiali a quelle dello schermo tramite operazioni matriciali. Quindi viene eseguito il clipping — rimozione della geometria fuori dal campo visivo della telecamera.

La rasterizzazione CPU divide ogni triangolo in pixel tramite l’algoritmo di scansione (scanline) o coordinate baricentriche. Per ogni pixel, il colore viene calcolato tenendo conto di texture, illuminazione e trasparenza. Il risultato viene scritto nel framebuffer — un array di pixel nella RAM.

La differenza principale dal rendering GPU è l’assenza di parallelismo a livello di pixel. La CPU elabora i pixel sequenzialmente o con parallelismo limitato su 4–8 core. Per un fotogramma 1080p (2 milioni di pixel) con texturing, sono necessari 15–30 ms sulla CPU contro 2–5 ms sulla GPU.

// Rasterizzazione CPU semplificata di un singolo triangolo
void rasterizeTriangle(uint32_t* buffer, int width,
    Vertex v0, Vertex v1, Vertex v2) {
    int minX = max(0, min(v0.x, v1.x, v2.x));
    int maxX = min(width, max(v0.x, v1.x, v2.x));
    int minY = max(0, min(v0.y, v1.y, v2.y));
    for (int y = minY; y <= maxY; y++) {
        for (int x = minX; x <= maxX; x++) {
            if (pixelInTriangle(x, y, v0, v1, v2)) {
                buffer[y * width + x] = 0xFF3498DB;
            }
        }
    }
}

La funzione esamina il bounding box del triangolo e verifica ogni pixel tramite coordinate baricentriche. Per milioni di pixel, questo ciclo viene eseguito in millisecondi sulla CPU, ma per scene complesse con migliaia di triangoli, il tempo cresce linearmente.

Confronto tra rendering CPU e GPU

La differenza tra CPU Rendering e GPU Rendering è determinata dall’architettura dei processori. La CPU è ottimizzata per attività sequenziali con predizione di salto, la GPU per parallelismo massiccio con migliaia di thread. Questa differenza fondamentale determina i settori di applicazione di ciascun approccio.

CPU Rendering vince in determinismo — gli stessi dati di input producono sempre lo stesso risultato. Questo è fondamentale per i framework UI, dove ogni pixel deve corrispondere al layout. La GPU può introdurre imprecisioni a causa di differenze di arrotondamento in virgola mobile tra driver.

Per la grafica 2D a bassa complessità (100–500 primitive), CPU Rendering è spesso più veloce della GPU grazie all’assenza di overhead per il trasferimento dei dati sul bus e la compilazione degli shader. Secondo Google Android Team (2025), il rendering software nel sistema View di Android richiede 2–3 ms per uno schermo tipico contro 3–5 ms con accelerazione hardware sulla GPU.

Dove viene usato CPU Rendering

Il rendering software rimane richiesto in scenari in cui la GPU non è disponibile, è superflua o non fornisce il determinismo necessario. Esaminiamo le principali aree di applicazione di CPU Rendering nello sviluppo moderno.

Framework UI e preparazione dei fotogrammi

Il sistema Android View renderizza tutti gli elementi UI sulla CPU e poi passa il risultato alla GPU per il compositing. Ogni View chiama onDraw(Canvas), che disegna su un Bitmap tramite CPU. Solo dopo HWUI compone i layer sulla GPU. Ciò garantisce un comportamento UI deterministico indipendentemente dal driver GPU.

UIKit su iOS inizia anch’esso con il rendering CPU. Core Animation renderizza CALayer in un backing store sulla CPU e poi invia le texture alla GPU. Secondo WWDC 2024, la fase software occupa il 30–50% del tempo di rendering del fotogramma, il resto è compositing GPU.

SVG e grafica vettoriale

Il rendering SVG viene tradizionalmente eseguito sulla CPU perché richiede la costruzione di curve di Bezier complesse e il loro riempimento. Librerie come librsvg e Skia elaborano SVG sulla CPU, suddividendo le curve in triangoli e colorandoli. Secondo Google Chrome Team (2025), Skia sulla CPU renderizza icone SVG in 0.3–1.5 ms sui processori mobili moderni.

Rendering PDF

I documenti PDF contengono grafica annidata complessa: font, elementi vettoriali, immagini raster e trasformazioni. Le applicazioni mobili renderizzano PDF sulla CPU tramite framework come PDFKit (iOS) e PdfRenderer (Android). La precisione di visualizzazione e il supporto dello standard PDF 2.0 richiedono l’elaborazione software di ogni elemento.

CPU Rendering nelle piattaforme mobili

Le piattaforme mobili implementano CPU Rendering tenendo conto dell’architettura ARM e del consumo energetico limitato. Vediamo come funziona il rendering software su Android e iOS.

Android: Canvas su CPU

Android Canvas con l’accelerazione hardware disattivata funziona interamente sulla CPU. La classe Canvas contiene metodi per disegnare primitive che vengono eseguiti tramite Skia — la libreria 2D di Google. Skia supporta backend software e GPU, commutando in base al flag hardwareAccelerated.

Canvas software crea un Bitmap nella RAM, ci disegna sopra comandi tramite Skia Software Renderer e poi lo visualizza sullo schermo. Tutte le operazioni vengono eseguite sulla CPU utilizzando istruzioni NEON per l’ottimizzazione. Secondo Skia Team (2025), l’accelerazione NEON fornisce un incremento del 40–60% per le operazioni di blend e mascheratura.

// Rendering software tramite Bitmap
val bitmap = Bitmap.createBitmap(200, 200, Bitmap.Config.ARGB_8888)
val canvas = Canvas(bitmap)
val paint = Paint().apply {
    color = Color.RED
    textSize = 24f
}
canvas.drawText("CPU Render", 10f, 50f, paint)
imageView.setImageBitmap(bitmap)

Il Bitmap viene creato nella memoria della CPU, su di esso vengono eseguiti comandi di disegno, quindi l’immagine finita viene visualizzata tramite ImageView. Questo approccio viene utilizzato per watermark, grafici e immagini dinamiche dove è importante il controllo completo su ogni pixel.

iOS: Core Graphics su CPU

Core Graphics è il framework di Apple per la grafica raster e vettoriale, che funziona principalmente sulla CPU. CGContext esegue tutte le operazioni di disegno in modalità software, utilizzando librerie altamente ottimizzate di Apple. Core Graphics alimenta Quartz 2D — un motore con 25 anni di storia.

Su iOS, Core Graphics passa il risultato a Core Animation per il compositing sulla GPU. Secondo Apple Engineering (2025), Core Graphics gestisce l’80% del disegno UI sulla CPU in UIKit, mentre il compositing Metal assembla texture pronte sulla GPU. UIGraphicsImageRenderer è un wrapper moderno per il rendering di immagini raster su CPU.

Ottimizzazione del rendering software

L’ottimizzazione di CPU Rendering è fondamentale per le prestazioni perché il rendering software è il principale consumatore di cicli CPU nei framework UI. Vediamo i metodi chiave per accelerare il disegno software.

Cache del risultato

Il metodo più efficace è non ridisegnare ciò che non è cambiato. Se il contenuto è statico, renderizzalo una volta in un Bitmap o CGLayer e copia il risultato pronto. In Android ciò è implementato tramite View.setLayerType(LAYER_TYPE_SOFTWARE) con un Bitpoint memorizzato nella cache. In iOS — tramite drawsAsynchronously e CALayer.shouldRasterize.

Minimizzazione dell’area di ridisegno

Utilizza dirty rectangles — tieni traccia di quali aree dello schermo sono cambiate e ridisegna solo quelle. Android ViewSystem calcola automaticamente la regione invalidata. iOS CALayer utilizza setNeedsDisplayInRect per limitare l’area di ridisegno.

Operazioni bit a bit e SSE/NEON

Per le operazioni sui pixel (blend, mascheratura), utilizza le istruzioni SIMD della CPU. Android Skia utilizza automaticamente NEON per i processori ARM. iOS Core Graphics è vettorizzato tramite il framework Accelerate. Secondo Google (2025), le operazioni di blend ottimizzate NEON in Skia vengono eseguite 3–5 volte più velocemente del codice scalare.

// Blending pixel ottimizzato NEON (ARM)
#include <arm_neon.h>
void blendNEON(uint32_t* dst, const uint32_t* src, int count) {
    for (int i = 0; i < count; i += 4) {
        uint8x16_t a = vld1q_u8((uint8_t*)(src + i));
        uint8x16_t b = vld1q_u8((uint8_t*)(dst + i));
        uint8x16_t r = vhaddq_u8(a, b);
        vst1q_u8((uint8_t*)(dst + i), r);
    }
}

Le istruzioni NEON elaborano 16 pixel (128 bit) in un’operazione. Combinato con il pipelining di ARM Cortex-X4, ciò fornisce una velocità effettiva fino a 500 milioni di pixel al secondo per copia e fusione software — sufficiente per uno schermo FullHD a 60 FPS.