Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Blend2D – 2D Vector Graphics Engine

blend2d.com

Post reply on HN
Print view View original

31–40 of 43 posts

Re: Blend2D – 2D Vector Graphics Engine

#31

Post by Matheus28 »

royjacobs wrote: post #2

This is very interesting. Especially since other vector engines are either unmaintained (like Antigrain) or extremely hard to build (Skia, Cairo). I do wonder if these kind of libraries shouldn't be supplanted by hardware accelerated rendering, though.

Skia is actually not too hard to build once you're used to gn and ninja. Download both of those tools and add them to your PATH, then cd into Skia's repo (that you just cloned):

    $ python tools/git-sync-deps
    $ gn gen out/release -args="is_official_build=true is_component_build=false"
    $ ninja -C out/release
This will build it as a static library. I believe by default it will try to use system libraries, you can make it use its own version of those libraries in this slightly more complicated process (which could be done with a script but I'm too lazy to write one right now):

    $ gn args out/release --list --short
This will print all the current build arguments, copy all the use_system_XXX = true, you'll have to modify those to be = false, and paste them into the text editor that will open once you run:

    $ gn args out/release
After that, run ninja to build

    $ ninja -C out/release
For the include files, you have to add at least these to your include directory:

    include
    include/config
    include/core
    include/effects
    include/gpu
On Windows, you might want to have two builds linking against different versions of the std lib (because of the whole iterator debug level stuff). Add these args: extra_cflags=["/MTd"] and extra_cflags=["/MT"] for debug/release builds (statically linked in this case).

Re: Blend2D – 2D Vector Graphics Engine

#32

Post by Matheus28 »

pjmlp wrote: post #20
orbifold wrote: post #15

Earlier quoted context omitted.

Skia is not so terrible, you just have to use their slightly obscure build tool. And it produces >8GB build artefacts with ~50 or more dependencies... Come to think of it is a bit of a nightmare.

I tried to use it a few times, but having to configure a Google build environment, without Google class workstations, meant I always gave up in the process and used Skia.Sharp instead.

I explained how to build it here, give it a try: https://news.ycombinator.com/item?id=19586159

Re: Blend2D – 2D Vector Graphics Engine

#33

Post by pjmlp »

Matheus28 wrote: post #32
pjmlp wrote: post #20

Earlier quoted context omitted.

I tried to use it a few times, but having to configure a Google build environment, without Google class workstations, meant I always gave up in the process and used Skia.Sharp instead.

I explained how to build it here, give it a try: https://news.ycombinator.com/item?id=19586159

Thanks for the heads up, but doing it across Windows/UWP, Android and iOS requires a bit more of effort than what you described, hence Skia.Sharp instead.

Re: Blend2D – 2D Vector Graphics Engine

#34

Post by Asm2D »

c-smile wrote: post #23

If to speak about UI needs then CPU rasterization is just half of the problem. 320 PPI display (a.k.a. "Retina") has 9 times more pixels than old, classic 96 PPI one. So just attaching new monitor will require 10 times better CPU in order to render the same UI. That if to use CPU rasterizers only. Obviously that above is not an option. That's why Direct2D and Skia contain as GPU as CPU rasterizers. That dualism compl…

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 16c/32t consumer CPUs this year I see no problem on this front as we will have the computational power to run several multithreaded renderers at the same time.

Blend2D has multithreaded rendering on roadmap - I have experience in this topic and everything in Blend2D was designed with multithreading in mind (banding for example). The implementation I'm planning would scale very well.

NV_path_rendering - I haven't seen any detailed comparison to be honest. Frame-rate is not enough to compare CPU vs GPU technology - both memory consumption and power consumption are important as well to calculate frame-rate per watt.

I cannot comment on Direct2D as it's not open source and it runs only on a single operating system. So I don't consider Direct2D as a competition at the moment.

Re: Blend2D – 2D Vector Graphics Engine

#35

Post by dmitriid »

royjacobs wrote: post #2

This is very interesting. Especially since other vector engines are either unmaintained (like Antigrain) or extremely hard to build (Skia, Cairo). I do wonder if these kind of libraries shouldn't be supplanted by hardware accelerated rendering, though.

> are either unmaintained (like Antigrain)

The author of Antigrain passed away a few years back, sadly.

It was and still probably is one of the best graphics libraries out there, and he was really hoping for a time when antialias-free, vector-based UI on high-pixel-density screens would become reality.

[1] Announcement in Russian: https://rsdn.org/forum/life/5377743.flat

"Maxim Shemanarev 1966-2013. Tragically, unexpectedly passed away in his home at 47." The discussion that follows names epileptic seizure as the cause of death.

[2] For example, this glorious text on text rasterization from 2007 http://www.antigrain.com/research/font_rasterization/index.h...

Re: Blend2D – 2D Vector Graphics Engine

#36

Post by Jasper_ »

raphlinus wrote: post #27
Jasper_ wrote: post #17

Earlier quoted context omitted.

GPUs really just aren't designed for 2D vector graphics. There is a litany of approaches (three separate ones from pcwalton's Pathfinder R&D alone), and all of them have various issues and tradeoffs. If your GPU has enough power for one of the more advanced approaches like Slug or Pathfinder1's compute shaders, then your CPU likely has enough for Blend2D and the bandwidth for the resulting texture upload. Pathfinder3…

When listing approaches, people should look at Skia Compute[0]. While it is true that traditional GPU's are not a super-great match for 2D graphics, modern GPU's are becoming more and more CPU-like, just with more parallelism. I haven't done careful quantitative evaluation of compute myself, but don't feel that any understanding of modern 2D graphics performance would be complete without that. [0]: https://github.com…

Wow, I haven't seen this before, thank you for the pointer! This reminds me of some of the work in this 2014 paper which used a compute-based algorithm on the GPU to implement vector textures. And of course the works of GLyphy and PF1. http://w3.impa.br/~diego/projects/GanEtAl14/

Re: Blend2D – 2D Vector Graphics Engine

#37

Post by schaefer »

underst0rm wrote: post #4
w0utert wrote: post #3

Very interesting and useful, but when I read the title I was hoping it would be something different. I would love to find some kind of stripped-down vector graphics engine that is fully geared towards real-time rendering of path-based graphics for games. For example to write retro-style games that use 2D vector graphics instead of textured quads. I've been writing a simple game that uses this graphics style, and so f…

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.

Re: Blend2D – 2D Vector Graphics Engine

#38

Post by c-smile »

Asm2D wrote: post #34
c-smile wrote: post #23

If to speak about UI needs then CPU rasterization is just half of the problem. 320 PPI display (a.k.a. "Retina") has 9 times more pixels than old, classic 96 PPI one. So just attaching new monitor will require 10 times better CPU in order to render the same UI. That if to use CPU rasterizers only. Obviously that above is not an option. That's why Direct2D and Skia contain as GPU as CPU rasterizers. That dualism compl…

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 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).

Re: Blend2D – 2D Vector Graphics Engine

#39

Post by Matheus28 »

pjmlp wrote: post #33
Matheus28 wrote: post #32

Earlier quoted context omitted.

I explained how to build it here, give it a try: https://news.ycombinator.com/item?id=19586159

Thanks for the heads up, but doing it across Windows/UWP, Android and iOS requires a bit more of effort than what you described, hence Skia.Sharp instead.

I'm doing exactly that though. To compile for iOS for example, create a separate output directory with `target_os="ios" target_cpu="arm64"`. You can see a few more examples here https://skia.org/user/build

Unfortunately, C++ libraries are a bit harder to use than other languages, hopefully the modules proposal will make this a lot easier.

Re: Blend2D – 2D Vector Graphics Engine

#40

Post by bitbang »

Pxtl wrote: post #8
vanderZwan wrote: post #5

Whenever SVG rendering engines come up, sooner or later the question of "which part of the SVG spec does it render incorrectly?" comes up. How does this one fare? I get the impression that often these rendering bugs are partially caused by old optimizations that break later spec changes or missed some edge cases the first time around, so I hope that means this engine does better than most because it's more recent, bu…

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.
Post reply on HN