Open X-Ryl669 opened 2 years ago
You can already use the SDK as-is on a embedded platform! The C header doesn't include a exported function for this, but the Zig implementation provides a "render chunk" function.
If you are willing to use the Zig implementation, you can achieve embedded rendering with less than 32k of RAM:
But i agree that this should be added to the C API as well.
I don't know how to use Zig on my system (ESP32). I don't know how hard it would be to rewrite the rendering engine in C++ (or at least C).
You can check out the render source code here:
https://github.com/TinyVG/sdk/blob/main/src/lib/rendering.zig#L287-L456
As it's written in Zig, it should be straightforward to port it to C or C++
@MasterQ32
Does it render a chunk of the svg or a rectangle of the final image?
Does it render a chunk of the svg or a rectangle of the final image?
No SVG rendering, we're doing TinyVG here ;)
But it just emits "pixel set commands", it doesn't even care about having a framebuffer in the first place. It will have some problems with blending tho if you (like in the image above) just draw into the framebuffer of a display directly and ignore alpha values completly
Would it be possible to add a partial rendering function to TinyVG? Typically, on embedded system, we don't have enough memory to store complete picture buffer in memory. So most system simply call the drawing loop multiple time, each time with a different drawing window.
Applied to a vector format, it means adding a "top/bottom/left/right" clipping to the rendering function so the rendering only happen within the same buffer, but a different output area of the image. That buffer is then transferred to the screen, and the rendering is called again with the next window.