Vrmac

> Those languages don't come with mechanisms to let you to make system calls directly or handle the precise memory structure of the data Here’s a C# library for Linux where I’m doing all these things https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Rea... As you see from that readme, the performance is pretty good too.

Linux XRender is functionally similar to Windows DirectComposition Linux does not have anything similar to Direct2D, despite it’s technically possible to make it. Here’s a proof of concept for ARMv7 Debian (Raspberry Pi4), on top of GLES 3.1: https://github.com/Const-me/Vrmac/?tab=readme-ov-file#2d-gra...

That’s a large library with tons of C++ which implement much more than just a video player. See readme on the main page of that repository. The video player in the VrmacVideo subfolder consumes Linux kernel APIs like libc, V4L2 and ALSA. It also uses C libraries which implement audio decoders. Most of the unsafe code you see in that subfolder is required to interop with these things. The player itself, including parsers for Mpeg4 and MKV containers, is memory-safe C# apart from very small pieces, most of them in that static class: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Con... And these functions are only used by Mpeg4 container parser. The parser for MKV containers didn’t need any unsafe at all. That project is an interesting showcase for .NET because many people incorrectly believe that handling high bitrate realtime au

> most libraries use the hell out of it Most libraries used in a typical LoB or web apps — yeah, probably. However, in performance-critical C# LINQ ain’t even applicable because Span<T> and ReadOnlySpan<T> collections don’t implement the IEnumerable<T> interface required by the LINQ functions. Here’s couple examples of relatively complicated logic which uses loops instead of LINQ: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Aud... https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Con...

> everyone writing their own unsafe vec implementation in C or C++ No one does that in C++, people use std::vector > I'm sure GNU's libstdc++, LLVM's libc++, and whatever Microsoft calls their C++ stdlib have had a laundry list of security bugs in their implementations True, C++ shares that thing with Rust. However, C# doesn’t. Their standard library is implemented in memory-safe code. Here’s the equivalent of std::vector, BTW https://source.dot.net/#System.Private.CoreLib/src/libraries... Admittedly, it’s not too important for standard libraries because most bugs already found and fixed by other people. Still, very important when designing custom data structures. > You really can't compare a GC'd language to Rust (or C or C++), at least not without acknowledging the inherent tradeoffs being made For most use cases these tradeoffs are not

I don't think they do. These formats are based on EBML, see the RFC link in my previous comment. That VINT encoding is not LEB128, it's better. BTW I once implemented my own parser in C#, see that source file: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Con...

Couple times in the past I have implemented GPU-targeted GUI renderers, here’s an example: https://github.com/Const-me/Vrmac?tab=readme-ov-file#vector-... https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/VAA... 2D graphics have very little in common with game engines. The problem is very different in many regards. In 2D, you generally have Bezier and other splines on input, large amount of overdraw, textures coming from users complicate VRAM memory management. OTOH, game engines are solving hard problem which are irrelevant to 2D renderers, like dynamic lighting, volumetric effects, and dynamic environment.

Don’t create new objects, instead use stack and/or unmanaged heap. This reduces the expressive power of the language, for example LINQ from the standard library is probably out because based on the delegates which require memory allocations. Still, the language is very usable even without GC allocations. For example, that library re-implements a subset of ffmpeg for Raspberry Pi4 running 32-bit Linux, with no memory allocations in runtime: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo