Multithreaded CPU Based Compositor in freestanding Os – Gaussian Blur Radius Animation 1→80
Posted: Sun Mar 01, 2026 9:35 am
The video is here: https://www.reddit.com/r/osdev/comments ... ositor_in/
What do you think?
I’ve been working on a freestanding x86-64 OS kernel and built a fully CPU-rendered compositor running entirely in kernel space.
Features:
• Multithreaded rendering
• Per-window compositing
• Alpha blending
• Separable Gaussian blur (measured upto around 250 fps in 1080p radius 15 with AVX512 in i51135g7 Cpu)
• Dirty region rendering
• Double buffering
• AVX2 + optional AVX-512 optimized paths
The demo video shows the blur radius increasing from 1 to 80 in real time.
Important:
The animation loop intentionally includes a 10ms sleep, so the video does not reflect the maximum blur performance. The blur engine itself runs significantly faster — this was just to make the radius progression visible.
At 1920×1080 on an Intel Core i5-1135G7, I measured ~250 FPS at radius 15 using AVX-512.
The compositor distributes work across multiple threads and applies blur only to dirty regions. Even though it’s fully CPU-based (no GPU acceleration), the motion feels close to something like Desktop Window Manager — but implemented purely in software.
The goal was to explore how far modern CPUs can push real-time compositing with careful threading, SIMD vectorization, and cache-aware design.
Would appreciate feedback or suggestions for further optimization.
What do you think?
I’ve been working on a freestanding x86-64 OS kernel and built a fully CPU-rendered compositor running entirely in kernel space.
Features:
• Multithreaded rendering
• Per-window compositing
• Alpha blending
• Separable Gaussian blur (measured upto around 250 fps in 1080p radius 15 with AVX512 in i51135g7 Cpu)
• Dirty region rendering
• Double buffering
• AVX2 + optional AVX-512 optimized paths
The demo video shows the blur radius increasing from 1 to 80 in real time.
Important:
The animation loop intentionally includes a 10ms sleep, so the video does not reflect the maximum blur performance. The blur engine itself runs significantly faster — this was just to make the radius progression visible.
At 1920×1080 on an Intel Core i5-1135G7, I measured ~250 FPS at radius 15 using AVX-512.
The compositor distributes work across multiple threads and applies blur only to dirty regions. Even though it’s fully CPU-based (no GPU acceleration), the motion feels close to something like Desktop Window Manager — but implemented purely in software.
The goal was to explore how far modern CPUs can push real-time compositing with careful threading, SIMD vectorization, and cache-aware design.
Would appreciate feedback or suggestions for further optimization.