Ein 540-Hz-OLED kann jetzt einen CRT nachahmen - und Windows ist das kaputte Glied

Weniger als eine Millisekunde. So kurz leuchtete ein CRT jeden Pixel auf, bevor der Phosphor verblasste, und genau deshalb sieht ein Quake-Match von 1998 auf einer 17-Zoll-Röhre in Bewegung immer noch schärfer aus als das meiste, was wir 2026 auf Panels mit zehnfacher Auflösung spielen. Sample-and-Hold-Displays verschmieren, Punkt. Die Pixelreaktion eines OLED ist praktisch sofort, aber das Bild steht trotzdem den ganzen Frame lang da, die Augen wandern darüber hinweg, und es verwischt trotzdem.

PC Gamer hat sich ausgiebig mit einer Lösung dafür beschäftigt, und ich war im selben Kaninchenbau unterwegs, also übersetze ich mal, was das für Bastler wirklich bedeutet.

Der Trick ist der CRT-Strahlsimulator von Blur Busters, der Algorithmus, den Mark Rejhon und Ex-Nvidia-Entwickler Timothy Lottes Ende 2024 zusammengebaut haben. Die Idee: Man nimmt Inhalte, die auf 60 fps festgenagelt sind, und zeichnet auf einem Display mit 240 Hz oder mehr jeden Frame als rollenden Scan mit simuliertem Phosphorabfall, statt das ganze Bild auf einmal aufblitzen zu lassen. Es ist der klügere Bruder der Black-Frame-Insertion. Klassisches BFI strobt mit 60 Hz, und viele ertragen das Flimmern nicht; der rollende Scan mit Phosphor-Fade ist deutlich augenschonender und liefert den Großteil derselben Klarheit. Angefangen hat es als RetroArch-Shader, wanderte in einen experimentellen Zweig von ShaderGlass und lebt jetzt als eigenständige App namens ShaderBeam vom Entwickler Mausimus.

Das Testgerät im Artikel ist Asus' ROG PG27AQWP-W, ein 540-Hz-OLED mit einem 720-Hz-Modus bei 720p. Mit so viel Spielraum ergibt sich die Zahl aus der Überschrift: Ein 60-fps-Spiel bekommt eine Bewegungsschärfe in der Größenordnung von nativen 540 fps, und dafür braucht es keine RTX 5090. Für einen Retro-Shooter, einen Emulator oder alles, was bei 60 gedeckelt ist, ist das der größte Sprung in der Bewegungsqualität, den es derzeit gibt - außer man kauft sich eine echte Röhre aus den Kleinanzeigen.

Warum es auseinanderfällt, und warum die GPU nichts dafür kann

Hier kommt der Teil, bei dem ich gleichzeitig genickt und geflucht habe. ShaderBeam kann sich nicht in die Rendering-Pipeline eines Spiels einklinken. Es funktioniert, indem es den Bildschirm aufnimmt und über ein transparentes Fenster darüberzeichnet - zwei Windows-Funktionen, die nie für frame-genaues Timing gedacht waren und dafür null Garantien geben. Ob der simulierte Strahl pünktlich landet, hängt davon ab, was der OS-Scheduler und der GPU-Treiber in dieser Millisekunde gerade tun wollen. Bekommt die App ihren GPU-Anteil nicht rechtzeitig, flackert es.

Mausimus' eigene Diagnose: Eine einzelne GPU hat mehr als genug Leistung dafür; das Problem ist, dass diese Leistung nicht vorhersehbar verteilt wird. Ich habe genug Frametime-Spitzen gejagt, um genau zu wissen, wie sich das anfühlt. Durchschnitt in Ordnung, 1%-Lows ruiniert, und im Einstellungsmenü gibt es nichts, dem man die Schuld geben könnte.

Die Liste der Workarounds liest sich wie ein Tuning-Forenthread von 2009: VRR aus, Treiberfunktionen deaktivieren, den zweiten Monitor abstecken, Prioritäten mit Process Lasso festnageln, einen Registry-Schlüssel anfassen und - mein Favorit - den Shader auf die integrierte GPU auslagern, damit er eigene Hardware bekommt. Es funktioniert. Es ist aber auch absurd, dass 2026 der saubere Weg zu CRT-Bewegung auf einem 540-Hz-OLED ein Dual-GPU-Hack ist.

Nvidias Antwort ist G-Sync Pulsar, das Strobing plus rollenden Refresh in Hardware erledigt und eine wahrgenommene Klarheit von 1.000 Hz verspricht. Gut, aber es läuft nur mit Nvidia, und eine OLED-Version gibt es noch nicht - für OLED-Besitzer existiert es also vorerst nicht.

Rejhons Wette: Die echte Lösung kommt, wenn das OS richtige Shader-Hooks freigibt oder wenn Monitore mit einer eigenen kleinen Verarbeitungs-GPU ausgeliefert werden, die die Strahlsimulation auf der Display-Seite erledigt - er verortet das in den 2030ern. Ich nehme beides. Windows hat bereits eine Display-Pipeline, einen Compositor und einen Low-Latency-Modus; was fehlt, ist ein Weg für Software zu sagen: "Zeig das genau in diesem Sub-Frame-Slot an." Bis es den gibt, werden die schnellsten Panels aller Zeiten weiter darauf warten, dass das Betriebssystem aus dem Weg geht.

Bild: grmwnr (homewiki) / CC BY-SA 3.0, source: https://commons.wikimedia.org/wiki/File:CRT_color_enhanced.png