Blend2D – 2D Vector Graphics Engine • Hacker News Board

Re: Blend2D – 2D Vector Graphics Engine

#41

Post by Pxtl » Sat, Apr 06, 2019, 5:57 PM UTC

bitbang wrote: post #40

Pxtl wrote: post #8

Earlier quoted context omitted.

Things like this convince me more and more that SVG is overdesigned and solving the wrong problem: The world needed a vector version of PNG far more than it needed a vector version of HTML/CSS.

That makes no sense. SVG _is_ the vector equivalent of PNG. Just because it's defined in an xml namespace that can be directly embedded in html, doesn't mean it is somehow bound to it.

I can't write JavaScript inside of a PNG. I can't reference external resources inside of a PNG. I can't reference CSS classes inside of a PNG. I can't animate a PNG. A PNG is a simple, dumb, uncomplicated file with a minimal surface area for vulnerabilities.

Re: Blend2D – 2D Vector Graphics Engine

#42

Post by underst0rm » Sun, Apr 07, 2019, 9:27 AM UTC

schaefer wrote: post #37

underst0rm wrote: post #4

Earlier quoted context omitted.

I have had great success using the ideas presented here ( http://m1el.github.io/woscope-how/index.html ) for simulation of traditional vector graphic screens. It is very fast and easily modified to allow for intensity modulation as well.

I really enjoyed your demo. Thank you.

Just to clarify. This was not my work. I have just used the ideas presented therein for my own works and found them easy to adapt and improve upon.

Re: Blend2D – 2D Vector Graphics Engine

#43

Post by Asm2D » Mon, Apr 08, 2019, 6:25 PM UTC

c-smile wrote: post #38

Asm2D wrote: post #34

Earlier quoted context omitted.

It's true that increasing the size of framebuffer demands more from CPU as well. According to my experience a single core on a modern machine has no problem to render real-time into a FullHD framebuffer at high frame rate (depending on the content of course, but UI is fine). This means that multithreaded renderers using 4 threads should be able to render to 4K framebuffer without any issues. Since AMD will release 16…

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…

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.