CPU Rendering: wat is het, principes en hoe software-rendering werkt

Wat is CPU Rendering?

CPU Rendering — een methode van beeldvorming waarbij alle fasen van de grafische pijplijn worden uitgevoerd op de centrale processor met behulp van wiskundige berekeningen. In tegenstelling tot de GPU, waar rasterisatie en texturering zijn ingebouwd in gespecialiseerde blokken, voert de CPU ze uit via universele SSE/NEON-instructies.

Historisch gezien was alle rendering softwarematig — de eerste grafische interfaces (Xerox Alto, 1973) en 3D-spellen (Quake, 1996) werden gerenderd op de CPU. De term «software renderer» werd synoniem met CPU Rendering. De overgang naar hardwareversnelling begon met de komst van betaalbare 3D-versnellers aan het einde van de jaren 1990, maar software-rendering bleef bestaan als fallback-mechanisme.

Volgens Akamai (2025) wordt CPU Rendering gebruikt in 35% van de mobiele websessies als primaire renderingmodus — op zwakkere apparaten, in emulators en wanneer GPU-versnelling is uitgeschakeld. Op iOS- en Android-platformen renderen UI-frameworks (UIKit, Android View) de eerste paar frames altijd op de CPU totdat de GPU-opdrachten zijn geïnitialiseerd.

Moderne processors ondersteunen SIMD-instructies (SSE4.2, AVX-512, ARM NEON) die gedeeltelijk de parallellisme van de GPU nabootsen. Het fysieke aantal kernen (4–12) en het ontbreken van gespecialiseerde rasterisatieblokken beperken echter de prestaties van CPU Rendering bij complexe graphics.

Fasen van software-rendering

De software-pijplijn omvat dezelfde fasen als de hardware-pijplijn: transformatie van hoekpunten, clipping, rasterisatie, texturering en pixeluitvoer. Het verschil is dat elke fase softwarematig wordt geïmplementeerd via C++ of assembleertaal, niet via vaste GPU-blokken.

Transformatie van hoekpunten in CPU Rendering wordt uitgevoerd door matrixvermenigvuldiging — 4x4 voor projectie en modellering. Bij 10.000 polygonen betekent dit 40.000 vectormultiplicaties per frame — een belasting die de CPU in 5–10 ms aankan met geoptimaliseerde code. Rasterisatie is de zwaarste fase, waarvoor de dekking van pixels voor elke driehoek moet worden berekend.

In mobiele processors versnelt ARM NEON software-rendering door vectorinstructies van 128 bits breed. Volgens ARM (2025) werkt een NEON-geoptimaliseerde software renderer 3–4 keer sneller dan een scalaire implementatie op een Cortex-X4 bij dezelfde kloksnelheid.

Hoe werkt software-rendering?

Software-rendering begint met het voorbereiden van de scène op de CPU: geometrie (hoekpunten, polygonen) wordt omgezet van wereldcoördinaten naar schermcoördinaten via matrixbewerkingen. Vervolgens wordt clipping uitgevoerd — het verwijderen van geometrie buiten het gezichtsveld van de camera.

Rasterisatie door de CPU verdeelt elke driehoek in pixels via het scanline-algoritme of barycentrische coördinaten. Voor elke pixel wordt de kleur berekend, rekening houdend met texturen, belichting en transparantie. Het resultaat wordt weggeschreven naar de framebuffer — een pixelarray in het werkgeheugen.

Het belangrijkste verschil met GPU-rendering is het ontbreken van parallellisme op pixelniveau. De CPU verwerkt pixels sequentieel of met beperkt parallellisme via 4–8 kernen. Voor een 1080p-frame (2 miljoen pixels) met texturering is 15–30 ms op de CPU nodig tegenover 2–5 ms op de GPU.

// Vereenvoudigde CPU-rasterisatie van een enkele driehoek
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;
            }
        }
    }
}

De functie doorloopt de bounding box van de driehoek en controleert de bijbehorende pixel via barycentrische coördinaten. Voor miljoenen pixels wordt een dergelijke lus in milliseconden op de CPU uitgevoerd, maar voor complexe scènes met duizenden driehoeken neemt de tijd lineair toe.

Vergelijking van CPU- en GPU-rendering

Het verschil tussen CPU Rendering en GPU Rendering wordt bepaald door de architectuur van de processors. De CPU is geoptimaliseerd voor sequentiële taken met vertakkingspredictie, de GPU voor massaal parallellisme met duizenden threads. Dit fundamentele verschil bepaalt de toepassingsgebieden van elke benadering.

CPU Rendering wint in determinisme — dezelfde invoergegevens geven altijd hetzelfde resultaat. Dit is essentieel voor UI-frameworks, waarbij elke pixel moet overeenkomen met het ontwerp. De GPU kan fouten introduceren vanwege floating-point afrondingskenmerken in verschillende drivers.

Voor 2D-graphics met lage complexiteit (100–500 primitieven) is CPU Rendering vaak sneller dan GPU vanwege het ontbreken van overhead voor gegevensoverdracht via de bus en shader-compilatie. Volgens Google Android Team (2025) duurt software-rendering in het View-systeem van Android 2–3 ms voor een typisch scherm tegenover 3–5 ms met hardwareversnelling op de GPU.

Waar wordt CPU Rendering gebruikt

Software-rendering blijft nodig in scenario’s waar de GPU niet beschikbaar, overbodig is of niet de vereiste determinisme biedt. Laten we de belangrijkste toepassingsgebieden van CPU Rendering in moderne ontwikkeling bekijken.

UI-frameworks en framevoorbereiding

Android View rendert alle UI-elementen op de CPU en geeft het resultaat vervolgens door aan de GPU voor compositie. Elke View roept onDraw(Canvas) aan, dat via de CPU op een Bitmap tekent. Pas daarna componeert HWUI de lagen op de GPU. Dit zorgt voor deterministisch UI-gedrag onafhankelijk van de GPU-driver.

UIKit in iOS begint ook met CPU-rendering. Core Animation rendert CALayer in een backing store op de CPU en stuurt de texturen vervolgens naar de GPU. Volgens WWDC 2024 neemt de softwarefase 30–50% van de frametijd in beslag, de rest is GPU-compositie.

SVG en vectorafbeeldingen

SVG-rendering wordt traditioneel op de CPU uitgevoerd, omdat het het construeren van complexe Bezier-curven en het vullen ervan vereist. Bibliotheken zoals librsvg en Skia verwerken SVG op de CPU door curven in driehoeken te verdelen en deze in te kleuren. Volgens Google Chrome Team (2025) rendert Skia op de CPU SVG-pictogrammen in 0.3–1.5 ms op moderne mobiele processors.

PDF-rendering

PDF-documenten bevatten complexe geneste afbeeldingen: lettertypen, vectorelementen, rasterafbeeldingen en transformaties. Mobiele applicaties renderen PDF op de CPU via frameworks zoals PDFKit (iOS) en PdfRenderer (Android). Weergavenauwkeurigheid en ondersteuning van de PDF 2.0-standaard vereisen softwarematige verwerking van elk element.

CPU Rendering op mobiele platformen

Mobiele platformen implementeren CPU Rendering rekening houdend met de ARM-architectuur en beperkt energieverbruik. Laten we bekijken hoe software-rendering werkt op Android en iOS.

Android: Canvas op de CPU

Android Canvas werkt met uitgeschakelde hardwareversnelling volledig op de CPU. De klasse Canvas bevat methoden voor het tekenen van primitieven die worden uitgevoerd via Skia — de 2D-bibliotheek van Google. Skia ondersteunt software- en GPU-backends en schakelt via de vlag hardwareAccelerated.

Software-Canvas maakt een Bitmap in het werkgeheugen, tekent er opdrachten op via de Skia Software Renderer en geeft deze vervolgens weer op het scherm. Alle bewerkingen worden uitgevoerd op de CPU met behulp van NEON-instructies voor optimalisatie. Volgens Skia Team (2025) levert NEON-versnelling een prestatieverbetering van 40–60% voor blend- en maskeringsbewerkingen.

// Software-rendering via 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)

De Bitmap wordt gemaakt in het CPU-geheugen, er worden tekenopdrachten op uitgevoerd en vervolgens wordt de resulterende afbeelding weergegeven via ImageView. Deze aanpak wordt gebruikt voor watermerken, grafieken en dynamische afbeeldingen waar volledige controle over elke pixel belangrijk is.

iOS: Core Graphics op de CPU

Core Graphics — het framework van Apple voor raster- en vectorafbeeldingen, dat voornamelijk op de CPU werkt. CGContext voert alle tekenbewerkingen uit in softwaremodus met behulp van de sterk geoptimaliseerde bibliotheken van Apple. Core Graphics ondersteunt Quartz 2D — een engine met een 25-jarige geschiedenis.

Op iOS geeft Core Graphics het resultaat door aan Core Animation voor compositie op de GPU. Volgens Apple Engineering (2025) verwerkt Core Graphics 80% van de UI-tekening op de CPU in UIKit, en Metal-compositie verzamelt de voltooide texturen op de GPU. UIGraphicsImageRenderer is een moderne wrapper voor het renderen van rasterafbeeldingen op de CPU.

Optimalisatie van software-rendering

Optimalisatie van CPU Rendering is cruciaal voor prestaties, omdat software-rendering de belangrijkste verbruiker van CPU-cycli is in UI-frameworks. Laten we de belangrijkste methoden voor het versnellen van software-rendering bekijken.

Cachen van resultaten

De meest effectieve methode is niet overtekenen wat niet is veranderd. Als de inhoud statisch is, render deze dan eenmalig in een Bitmap of CGLayer en kopieer het voltooide resultaat. In Android is dit geïmplementeerd via View.setLayerType(LAYER_TYPE_SOFTWARE) met een gecachte Bitmap. In iOS — via drawsAsynchronously en CALayer.shouldRasterize.

Minimaliseren van het overtekengebied

Gebruik dirty rectangles — houd bij welke delen van het scherm zijn veranderd en teken alleen deze opnieuw. Android ViewSystem berekent automatisch de ongeldig verklaarde regio. iOS CALayer gebruikt setNeedsDisplayInRect om het overtekengebied te beperken.

Bitsgewijze bewerkingen en SSE/NEON

Gebruik voor pixelbewerkingen (blend, maskeren) de SIMD-instructies van de CPU. Android Skia gebruikt automatisch NEON voor ARM-processors. iOS Core Graphics is gevectoriseerd via het Accelerate framework. Volgens Google (2025) worden NEON-geoptimaliseerde blend-bewerkingen in Skia 3–5 keer sneller uitgevoerd dan scalaire code.

// NEON-geoptimaliseerde pixelblending (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);
    }
}

NEON-instructies verwerken 16 pixels (128 bits) in één bewerking. In combinatie met de ARM Cortex-X4-pijplijn levert dit een doorvoer van tot 500 miljoen pixels per seconde bij softwarematig kopiëren en mengen — voldoende voor een FullHD-scherm met 60 FPS.