-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for embedded system #1
Comments
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? |
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.
The text was updated successfully, but these errors were encountered: