Hacker News new | ask | show | jobs
by c-smile 2634 days ago
Well, CPU rasterization is always O(N) complex (where N is number of pixels on screen). Multithreading here just adds constant multiplier that according to the math will still lead to O(N).

While GPU rasterization, from application perspective, is near O(1) - does not depend on number of pixels in ideal circumstances.

And having multiple threads to render UI is not desired - there are too many CPU consumers on modern desktop, e.g. online radio that is playing now, etc.

I am not saying that CPU rasterization makes no sense. Quite contrary. As a practical example: in Sciter on Linux/GTK I am using Cairo backend by default as OpenGL inside GTK windows is horrible. So Skia does not help there at all - Cairo and its CPU rasterizer is used.

If we would have something that allows to rasterize paths 5-10 times faster than current Cairo - it will solve all current desktop needs I think.

In principle 192 PPI resolution for desktop monitors of practical sizes (24 inch, 3840x2160 pixels) is OK - human eye will not be able to see separate pixels. Pretty much the same number of pixels is on mobiles ( iPadPro: 2732x2048 ). These are targets that need to be considered.

Practical requirements:

Take HN site in browser. Open it full screen. Decent 2D library should be able to rasterize that amount of text with 60 FPS (e.g. kinetic scrolling).
1 comments
Asm2D 2631 days ago
I don't know what rasterizers you refer to with:

  "CPU rasterization is always O(N) complex (where N is number of pixels on screen)"
But this is definitely not the Blend2D case. I think you will not find rasterizers in production with such properties in software-based 2D rendering as that would be really inefficient. Path boundary matters and that is often the worst case scenario, but Blend2D does much better than this, for example.

I see no problem with multithreading, because it doesn't mean that all CPU cores will be busy with rendering, it means that the total time required to render a frame will be much lower while utilizing CPU power in a more distributed way instead of stressing a single core. You can use 2-4 threads on 8 core machine, for example, leaving the rest for other real-time tasks if required. Applications that use GPU for 2D rendering also use the full power of the GPU, if available.

Single core performance is stagnating while the number of CPU cores is increasing, so it's simply practical to design software to take advantage of that.

link