Vrmac

> For how things actually work in practice Another version of the demuxer, way simpler: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Con... A complete mpeg4 media file, with enough features to play the content with hardware decoding: https://github.com/Const-me/Vrmac/blob/master/VrmacVideo/Con...

I agree about Python or PHP. However, for Java or modern C#, in my experience the performance is often fairly close. When using either of them, very often one doesn’t need C++ to be good enough. Here’s an example, a video player library for Raspberry Pi4: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo As written on that page, just a few things are in C++ (GLES integration, audio decoders, and couple SIMD utility functions), the majority of things are in C#. Still, compared to VLC player running on the same hardware, the code uses same CPU time, and less memory.

To be fair, in modern GL versions they fixed some of these things. In GLES 3.1 which I used a lot on Pi4 https://github.com/Const-me/Vrmac/ GPU vertex buffers and shaders worked fine, GLSL compiler in the drivers worked fine too. However, others issues are still present. There’s no shaders bytecode, they have an extension to grab compiled shaders from GPU driver to cache on disk, but it doesn’t work. The only way to create shaders is separate compile and link API calls. Texture loading and binding API is still less than ideal.

Here's how I did that https://github.com/Const-me/Vrmac/blob/master/Vrmac/Draw/VAA... Inexact but IMO pretty good still. With some modifications, the approach can be used in GLES2.

On Windows, the graphics story is more or less OK. The OS includes Direct2D and DirectWrite user-facing APIs. It’s now possible to implement an equivalent on all modern platforms which have a 3D GPU. An open-source example in C# https://github.com/Const-me/Vrmac#vector-graphics-engine That particular one requires GLES 3.1, but I’m sure (did it before) it’s also possible to implement comparable stuff on top of GLES2. Waiting for target devices to have TFlops of FP32 performance, and good support for compute shaders, is less than ideal. Many currently sold phones, tablets, laptops, and even some desktop PCs, have limited GPGPU capabilities and/or performance. These currently sold devices gonna stay in use for at least couple years in the future. Rendering things on CPU is less than ideal, because many devices have high-rez displays yet rela

If I wanted to create a web browser from the ground up, I would do that in C#. And I would not use graphical libraries such as Xlib or Cairo, none of them has good hardware support. I think the right way is building on top of 3D GPU APIs, like I did there: https://github.com/const-me/Vrmac#vector-graphics-engine

Why aren’t you using higher-level memory safe languages for that? In C#, the runtime checks for integer overflow can be enabled with a single compiler switch. The switch is not set by default for some reason, but easy enough to enable manually, a single line in *.csproj file. If you think GC performance is not good enough, see that proof of concept: https://github.com/Const-me/Vrmac/tree/master/VrmacVideo/Con... That C# code implements parser for Mpeg4 format. That format is way more complicated than GIF or even PDF, yet that code runs fine even on very slow computers (Raspberry Pi 4). There’s another similar one in that project for MKV format.

On Windows, the best way is often Direct2D https://docs.microsoft.com/en-us/windows/win32/direct2d/dire... On Linux, you have to do that yourself. The best approach depends on requirements and target hardware. The simplest case is when your lines are straight segments or polylines of them, you have decent GPU, and you don’t have weird requirements about line caps and joins. In that case, simply render a quad per segment, using 8x or 16x MSAA. Quality-wise, the results at these MSAA levels are surprisingly good. Performance-wise, modern PC-class GPUs (including thin laptops and CPU-integrated graphics in them) are usually OK at that use case even with 16x MSAA. If MSAA is too slow on your hardware but you still want good quality AA, it’s harder to achieve but still doable. Here’s a relevant documentation from my graphics library for Raspbe