VKVG: Vulkan Vector Graphics With A Cairo-Like API

[phoronix]

Phoronix: VKVG: Vulkan Vector Graphics With A Cairo-Like API

The latest nifty open-source Vulkan project we have come across worthy of a shout-out is VKVG. VKVG is short for Vulkan Vector Graphics and is a C library for drawing 2D vector graphics using the Vulkan graphics API...

http://www.phoronix.com/scan.php?page=news_item&px=VKVG-Vulkan-Vector-Graphics

[VikingGe]

Current Status:
[...]
- Nice logo

Really?

Anyway, sounds interesting, let's see if it gets adopted where it makes sense. Although to be fair, Vulkan support as a hard requirement for anything but games is probably not going to happen within the next 3+ years, there's still plenty of hardware around with no Vulkan support.

[bachchain]

With the widely-used Cairo vector graphics library lacking a Vulkan back-end, a developer started crafting his own library while keeping the API as close as possible to Cairo.

Then why didn't he just work on adding a Vulkan back-end to Cairo? Isn't that the point of OSS?

[Mercyful Fate]

Then why didn't he just work on adding a Vulkan back-end to Cairo? Isn't that the point of OSS?

Indeed. https://www.phoronix.com/scan.php?pa...LESv3-Work-OSG

[tessio]

Then why didn't he just work on adding a Vulkan back-end to Cairo? Isn't that the point of OSS?

Pretty sure messing with a big project like Cairo would be much harder. Later some Cairo dev can look at this project and copy what is necessary.


By the way.. "why didn't he just work on..." is cancerous.. stop spreading cancer.

[bachchain]

Pretty sure messing with a big project like Cairo would be much harder.

Cairo's source is less than 170k LOC

By the way.. "why didn't he just work on..." is cancerous.. stop spreading cancer.

If you have a problem with the implication that contributing to an existing project is trivial compared to a complete re-implementation, that's your fault.

[Marc Driftmeyer]

I'd rather they work independently and decide on their own licensing that will comply with Khronos and go from there. Perhaps they want it to fold into the entire Khronos ethos and not be tied to Cairo? I'd wager GNOME would gladly work with it over keeping Cairo around if it proves worthy.

[wizard69]

Why C? Seriously we already have Cairo. One of the biggest problems in Linux land is tge willingness to embrace or even experiment with new tech. The tech im talking about here is compiler / language tech.

Why development around a modern language like Rust, Swift and a few others, will lead to an expansion in the Linux software based. More importantly quality will go up. People complain about softwarw quantity and quality all the time but the Linux world is stuck on PDP8 level tech.

[polarathene]

Why C? Seriously we already have Cairo. One of the biggest problems in Linux land is tge willingness to embrace or even experiment with new tech. The tech im talking about here is compiler / language tech.

Why development around a modern language like Rust, Swift and a few others, will lead to an expansion in the Linux software based. More importantly quality will go up. People complain about softwarw quantity and quality all the time but the Linux world is stuck on PDP8 level tech.

Probably because they're most comfortable with C as a low level language? Would be interesting to see on Rust with vulkano which is meant to make working with Vulkan easier. I'm doing my own project similar to another that was done in C/C++ but with Rust, mostly because that's the low level language I'm most comfortable with.

[microcode]

Why C? Seriously we already have Cairo. One of the biggest problems in Linux land is tge willingness to embrace or even experiment with new tech. The tech im talking about here is compiler / language tech.

Why development around a modern language like Rust, Swift and a few others, will lead to an expansion in the Linux software based. More importantly quality will go up. People complain about softwarw quantity and quality all the time but the Linux world is stuck on PDP8 level tech.

How is this "one of the biggest problems in linux land". Have you ever written software? Language choice isn't such a big deal, but I can think of many benefits to writing this in C. Firstly, Vulkan itself uses the C calling conventions, so this requires no intermediate adapters (and the language conventions match the API conventions perfectly. Secondly, C compilers are mature, they generate fast and predictable code, and they are most likely to already be present on the development machines of whoever is using a library like this.

C99/C11 is not "PDP8 level tech", fundamentally very little about computers (especially CPUs) has changed since the PDP-7 (and the first real C compilers were actually for the PDP-11), and most available operating systems with Vulkan implementations are basically like UNIX in most important ways. Virtually nothing about the environment has changed, why should the language have to change if it is not constraining the solution?

Why C? Because it's good.