Hacker News new | past | comments | ask | show | jobs | submit login
Vkvg: Vulkan vector drawing, trying to stay close to Cairo API (github.com/jpbruyere)
78 points by adamnemecek on Aug 11, 2018 | hide | past | favorite | 10 comments



Can anyone shed some light on the patent status of rendering convex polygons? Last I checked, pretty much every method seemed to be patented in the US. Here, the stencil buffer method is used, which also seems to be patented, although the method was described in "OpenGL Programming Guide, 3rd Edition" from 1999, possibly earlier.


Please don't; often commercial/corporate developers are directed to never look for or reference patents in the course of their work. Especially here, it could make the difference between knowing and unknowing infringement - often a damages multiplier if it comes to a dispute. Seriously, if you have a concern I highly suggest you leave that to your legal advisors.

I am not a lawyer, and I'm certainly not your lawyer.


Does this still apply if the code has already been written?


> if you have a concern I highly suggest you leave that to your legal advisors.


What patent are you referring to?


For example https://patents.google.com/patent/US9311738 or https://patents.google.com/patent/US7432937. The second patent mentions an alpha buffer which has stencil buffer operations instead of a stencil buffer, not sure if it matters how the thing is called. Although the second patent could maybe be worked around by incrementing the alpha buffer instead of toggling it. This would fail with polygons with a winding number higher than 256 (or 2^23 with 32 bit floating point), so good enough for almost all applications.

Several other patents can be found when searching for "patent stencil polygon", but I don't know if they are relevant or not.


I'm very curious about the performance gains from using Vulkan instead of OpenGL. How would this compare performance wise to nanoVG?


Yes, the multithreading on the GPU picks up good performance in OpenGL and the extensions for compositing make a huge difference due to drawing all the vectors on the screen quickly. NanoVG uses a single header file for a lot of operations so it's hard to beat where performance is concerned it mostly talks directly to the GPU. I think if precompiling shaders and using indirect draw calls with Vulkan can reduce the glDrawArray/Elements bottleneck then it will have succeeded at delivering better performance. There is a "depends how you use it" and "how you measure performance" issue comparing any and all GPU based vector libraries. Also, the data structures supporting the paths will affect things a lot since there is a ton of allocating and freeing memory going on. Comparing the two you could potentially run hundreds of different tests just to get the answer to this question.


At a quick glance, I would not expect a large difference, due to the lack of multithreading.


I am a Cairo user that wants to port some code to the GPU. Really interested to hear succes stories on macOS and windows...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: