High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
1–10 of 36 posts
Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
#2Also checkout blaze: https://gasiulis.name/parallel-rasterization-on-cpu/
Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
#3This looks interesting; recently I wrote some code for rendering high precision N-body paths with millions of vertices[0], I wonder if a GPU implementation this RLE representation would work well and maintain simplicity.
Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
#4Also checkout blaze: https://gasiulis.name/parallel-rasterization-on-cpu/
the demo is astonishing
Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
#5Side question. Is there some kind of benchmark to test the correctness of renderers?
Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
#6Side question. Is there some kind of benchmark to test the correctness of renderers?
Correctness of what exactly? It's a "render" of reality-like environment, so all of them make some tradeoff somewhere, and won't be 100% "correct" at least compared to reality :)
Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
#7Side question. Is there some kind of benchmark to test the correctness of renderers?
This was the original goal of the Cornell box (https://en.wikipedia.org/wiki/Cornell_box, i.e. carefully measure the radiosity of a simple, real-world scene and then see how closely you can come to simulating it).
For realtime rendering a common thing to do is to benchmark against a known-good offline renderer (e.g. Arnold, Octane)
Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
#8Side question. Is there some kind of benchmark to test the correctness of renderers?
Correctness of what exactly? It's a "render" of reality-like environment, so all of them make some tradeoff somewhere, and won't be 100% "correct" at least compared to reality :)
Correctness with respect to the benchmark. A slow reference renderer could produce the target image, and renderers need to achieve either exact or close reproduction to the reference. Otherwise, you could just make substantial approximations and claim a performance victory.
Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
#9Side question. Is there some kind of benchmark to test the correctness of renderers?
Correctness of what exactly? It's a "render" of reality-like environment, so all of them make some tradeoff somewhere, and won't be 100% "correct" at least compared to reality :)
Bezier curves can generate degenerate geometry when flattened and stroke geometry has to handle edge cases. See for instance the illustration on the last page of the Polar Stroking paper: https://arxiv.org/pdf/2007.00308
There are also things like interpretting (conflating) coverage as alpha for analytical antialiasing methods, which lead to visible hairline cracks.
Re: High-performance 2D graphics rendering on the CPU using sparse strips [pdf]
#10Fascinating project. Based on section 3.9, it seems the output is in the form of a bitmap. So I assume you have to do a full memory copy to the GPU to display the image in the end. With skia moving to WebGPU[0] and with WebGPU supporting compute shaders, I feel that 2D graphics is slowly becoming a solved problem in terms of portability and performance. Of course there are cases where you would a want a CPU renderer. Interestingly the web is sort of one of them because you have to compile shaders at runtime on page load. I wonder if it could make sense in theory to have multiple stages to this, sort of like how JS JITs work, were you would start with a CPU renderer while the GPU compiles its shaders. Another benefit, as the author mentions, is binary size. WebGPU (via dawn at least) is rather large.
[0] https://blog.chromium.org/2025/07/introducing-skia-graphite-...