HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
Const-me
Vrmac
C#2020–2024
Const-me / Vrmac

Vrmac

Vrmac Graphics, a cross-platform graphics library for .NET. Supports 3D, 2D, and accelerated video playback. Works on Windows 10 and Raspberry Pi4.

3Distinct people
86Mentions
0Explicit recommenders
130GitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

Vrmac Graphics, a cross-platform graphics library for .NET. Supports 3D, 2D, and accelerated video playback. Works on Windows 10 and Raspberry Pi4.

GitHub

Where it is used

No documented product use has been verified yet.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 9:02:44 AM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by year86 dated mentions

Observed mentions: 2020-05-18 12:01:50 UTC to 2024-10-09 23:45:11 UTC.

01020302020-01-01 00:00:00 UTC to 2021-01-01 00:00:00 UTC (exclusive): 30 mentions; 1 submissions, 29 comments20202021-01-01 00:00:00 UTC to 2022-01-01 00:00:00 UTC (exclusive): 34 mentions; 0 submissions, 34 comments2022-01-01 00:00:00 UTC to 2023-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments20222023-01-01 00:00:00 UTC to 2024-01-01 00:00:00 UTC (exclusive): 6 mentions; 0 submissions, 6 comments2024-01-01 00:00:00 UTC to 2025-01-01 00:00:00 UTC (exclusive): 8 mentions; 0 submissions, 8 comments2024

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
20202020-01-01 00:00:00 UTC2021-01-01 00:00:00 UTC30129
20212021-01-01 00:00:00 UTC2022-01-01 00:00:00 UTC34034
20222022-01-01 00:00:00 UTC2023-01-01 00:00:00 UTC808
20232023-01-01 00:00:00 UTC2024-01-01 00:00:00 UTC606
20242024-01-01 00:00:00 UTC2025-01-01 00:00:00 UTC808

What Hacker News says

34 sources
> unless you're doing fun patterns like 'where TComparer : IEqualityComparer<T>,struct` These fun patterns are precisely generic type constraints I mentioned in my comment. I do use them when performance matters, here’s an open-source example: https://github.com/Const-me/Vrmac/blob/1.2/Vrmac/Draw/Main/I... That code is from a 2D vector graphics library, these interface methods may be called at 10 kHz frequency or more. Displays are often 60 Hz, the methods are called couple times for every vector path being rendered. > If you poke around at the internals of System.Linq you'll see there's a lot of checking to use specialized types depending on the collection in order to minimize costs. Linq is awesome, but I’m pretty sure it was designed for usability first, performance second. I tend to avoid Linq (and dynamic memory allocations in gener
Read the rest
al; delegates are using the heap) on performance-critical paths. YMMV but in most of the code I write, these performance-critical paths are taking way under 50% of my code bases. > 'new' generic constraint is definitely not zero cost If you mean the overhead of Activator.CreateInstance<T> when generic code calls new() with the generic type, I’m not 100% certain but I think it’s fixed now. According to https://source.dot.net/, that standard library method is marked with [Intrinsic] attribute, the runtime and JIT probably have optimizations for value types.
In Why Is C Faster Than Java (2009)
> a message queue type of service, where the desire was to minimize latency and to have consistent performance over prolonged use. Your requirements are probably similar to this C# queues class: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Aud... That library decodes and plays realtime video + audio, both low latency and consistent performance over prolonged use were rather important. BTW that code runs on Raspberry Pi4, CPU performance is a fraction of what you’d expect on modern desktops or servers.
In My negative views on Rust
> I think you can tessellation on the CPU in an adaptive fashion (e.g. based on curvature or similar) and update that on a per frame (add, remove tessellation points) basis rather than re-tesselating from scratch each frame. The GPU’s hardware-implemented tessellation is (a) not compatible enough. It’s OK on Windows because Microsoft requires them for GPU vendors to declare the support of Direct3D 11. On the rest of the platforms, support across GPU vendors varies. And (b) doesn’t help much for 2D vector graphics. The hardware tessellation can be good for terrain, trees, or other triangle meshes in 3D space. Doesn’t help much for these Bezier curves/elliptical arcs for 2D shapes. Especially so for stroked paths. Counter-intuitively, stroked paths are harder to render than filled ones. The offset of Bezier spline is not representable as an
Read the rest
other Bezier spline. Also, strokes have more parameters on input: line caps, join types, dashes, miter limit, etc. > The main limitation in JS is the lack of really great multithreading Also lack of SIMD. Also, the code in general is slow compared to C++, C# and many other statically typed languages. It’s incredibly hard to generate fast code from very dynamic languages like JS or Python, where everything is a hash map. > I do not think you need it here. Here’s my code which offloads CPU-bound pieces of 2D rendering to other CPU cores: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Draw/Tes... Multithreading helped a lot.
In A novel technological approach to vector graphics (“Vector Graphics Complexes”)
This project https://github.com/Const-me/Vrmac implements unified keyboard+mouse input API over 3 distinct lower-level APIs: Win32 messages, XCB packets, and Linux raw input. Here’s for raw input: https://github.com/Const-me/Vrmac/tree/master/Vrmac/Input/Li... All 3 have unique quirks, yet I would not say they significantly affected the rest of the library. I think for the USB in that OS, a C API with intentionally very narrow scope would be OK for the job. The main reason why the real-life code is so complex is that scope being very wide. We have USB 2 and 3, mass storage, two-way audio, cameras and GPUs, hubs and composite devices, numerous wireless protocols on top, OTG, power delivery, power saving features, and more.
In It's Time for Operating Systems to Rediscover Hardware
You don't need any of that to do system programming in C#. Startup time of JIT runtime is not too bad. Similarly, garbage collector is fine if you don't load it too much (neither allocations/second nor bytes/second). Here's my almost decade-old open source code which works for hours allocating very little (the process gets killed by the OS if exceeds 11MB of RAM): https://github.com/Const-me/SkyFM Here's somewhat similar modern code, also multimedia related: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo
In C# for Systems Programming
> have you needed any non-vertical ops that are not in that list? Yes indeed. I rarely using SIMD for vertical-only ops, for such use cases GPUs are very often better than CPUs. I’ve already wrote an example in my previous comment. It’s possible to emulate with the stuff you have, however _mm256_blend_pd is very fast instruction, a single cycle of latency. The highway’s emulation is going to be way more expensive. You probably compiling your UpperHalf() into _mm256_extractf128_pd and Combine() into _mm256_insertf128_pd, that’s 2 instructions and (on Skylake) 6 cycles of latency instead of 1 cycle. 6 cycles instead of 1 cycle is a large overhead in that context. That particular small matrix multiplication is called rather often. I only optimizing code when the profiler tells me so. For the majority of CPU bound code in that project, Eigen’
Read the rest
s implementation is actually good enough. I’ve searched the source code of that project (CAM/CAE software). Here’s the list of the shuffle intrinsics I use, some of them a lot: _mm256_blend_pd, _mm_blend_ps, _mm_blend_epi32, _mm256_permute2f128_pd, _mm256_permute_ps, _mm256_permute4x64_pd, _mm256_permutevar8x32_ps, _mm256_permutevar8x32_epi32, _mm_permute_ps, _mm_permute_pd, _mm_insert_ps, _mm_movehdup_ps, _mm_moveldup_ps, _mm_loaddup_pd, _mm_extract_ps, _mm_dp_ps, _mm_extract_epi32, _mm_extract_epi64, _mm_shuffle_epi32. A similar list for this project https://github.com/Const-me/Vrmac (a GPU-centric library for 3D and 2D graphics, not using any AVX): _mm_shuffle_epi8, _mm_alignr_epi8, _mm_shuffle_epi32, _mm_shuffle_ps, _mm_addsub_ps (that one is vertical but still missing from highway), _mm_insert_epi32, _mm_insert_ps, _mm_extract_ps, _mm_extract_epi16, _mm_movehdup_ps, _mm_dp_ps. BTW the project is portable between AMD64 and ARMv7, I have tons of #ifdef there to support NEON which differs substantially, there’s stuff like vrev64q_f32 and vextq_f32, 64-bit SIMD vectors, and quite a few other instructions missing on AMD64. Even if you expose all the missing horizontal stuff in highway — won’t be much better than intrinsics. Such code ain’t gonna use AVX512 when available. Only going to inflate the software complexity for no good reason, by adding an unneeded layer of abstraction between the application’s code and the actual hardware.
In AVX512/VBMI2: A Programmer’s Perspective
BGFX is a general-purpose 3D graphics engine, not a GUI nor vector graphics framework. Nanovg is an awesome vector graphics library, but has limitations. (1) no ClearType, I fixed in my fork: https://github.com/Const-me/nanovg (2) The only way to get AA is hardware MSAA, unfortunately many popular platforms like Raspberry Pi don’t have good enough hardware to do it fast enough. Nanogui is built on top of Nanovg, shares the limitations. I agree with the OP that Cairo and Skia are the only viable ones for Linux. It’s sad because Windows has Direct2D for decades now (introduced in Vista), and unlike 2006, now in 2021 Linux actually has all the lower-level pieces to implement a comparable equivalent. Here’s a proof of concept: https://github.com/Const-me/Vrmac#vector-graphics-engine
In So you want to write a GUI framework
> it is genuinely hard to write an abstraction that provides adequate control of advanced GPU features (such as the compute capabilities) across subtly different low-level APIs. That’s a solved problem in C++, see this library: http://diligentgraphics.com/diligent-engine/ > The rasterization techniques used in 3D are poorly suited to 2D tasks like clipping to vector paths or antialiasing That’s subjective, I think these techniques are awesome fit for 2D. See this library: https://github.com/Const-me/Vrmac#2d-graphics BTW I have recently documented my antialiasing algorithm: https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/VAA... > these traditional techniques can start to perform very badly in 2D once there are lots of blend groups or clip regions involved, since each needs its own temporary buffer and draw call. One doesn’t neces
Read the rest
sarily need temporary buffers or draw calls for that, can also do in the shaders, merging into larger draw calls. > What this comes down to is instructing the operating system to embed a video or 3D view in some region of our window, and this means interacting with the compositor. That indeed works in practice, but I don’t believe the approach is good. Modern GUI frameworks are using 3D GPUs exclusively. They don’t need much efforts to integrate 3D-rendered content. As for the video, one only needs a platform API to decode and deliver frames in GPU textures. Microsoft has such API in the OS: https://docs.microsoft.com/en-us/windows/win32/api/mfmediaen... Once upon a time wanted to do the same on embedded Linux, wasn’t easy but still doable on top of V4L2 kernel calls: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo
In So you want to write a GUI framework
> my point is that the GPU really is not the "first-class citizen" that the CPU is. On Windows GPU is the first-class citizen since Vista. In Vista, Microsoft started to use D3D10 for their desktop compositor. In Windows 7 they have upgraded to Direct3D 11. The transition wasn’t smooth. Only gamers had 3D GPUs before Vista, many people needed new computers. Technically, Microsoft had to change driver model to support a few required features. On the bright side, now that XP->Win7 transition is long in the past, and 3D GPUs are used for everything on Windows. All web browsers are using D3D to render stuff, albeit not directly, through the higher-level libraries like Direct2D and DirectWrite. Linux doesn’t even have these higher-level libraries. They are possible to implement on top of whichever GPU API is available https://github.com/Const-
Read the rest
me/Vrmac#vector-graphics-engine but so far nobody did it well enough. It’s very similar situation with GPU compute on Linux. The kernel and driver support has arrived by now, but the higher-level user mode things are still missing. P.S. If you’re on Linux, pretty sure you can still refactor your compute shaders the same way and they will work fine afterwards. You obviously don’t have ID3D11Query/ID3D11Fence but most GPU APIs have replacements: VkFence(3) in Vulkan, EGL_KHR_fence_sync/GL_OES_EGL_sync/VG_KHR_EGL_sync extensions for GL and GLES, etc.
In The free lunch is over: a fundamental turn toward concurrency in software (2005)

Showing the 15 most recent of 34 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.