Where rendering happens is one of the decisions that separates a system that scales cleanly from one that doesn’t. This piece expands on the rendering layer covered in our system architecture guide, with the reasoning behind the trade-off in full.
Rendering Architectures
Edge rendering sends structured data — a JSON payload, for instance — from the cloud, and the edge device itself renders that into the final bitmap image: fonts, layout, positioning, all handled locally. The advantage is data volume. A structured payload can be a few bytes, which is extremely bandwidth- and power-efficient over a constrained radio link. The cost is real demand on the edge MCU’s compute and memory — it needs enough capability to run font rendering and layout logic, not just display a finished image.
Cloud-to-image rendering does the opposite: the server handles layout centrally, converts it directly to a 1-bit or 4-bit image, and ships that image — sliced if needed — to the device as-is. Edge hardware stays minimal: no font libraries, no layout engine, no local rendering logic. Complex typography gets solved once, centrally, instead of replicated across every device’s firmware. The cost shifts to data volume — a rendered image, even compressed, is meaningfully larger than structured data.
Hybrid Template Rendering: Hybrid Template Rendering combines both approaches: the cloud manages the visual template, while the edge device updates dynamic data fields locally. It reduces bandwidth compared with full image updates while avoiding the complexity of fully local rendering.
Neither is universally correct. The right choice depends on edge hardware capability, content complexity, and how constrained your connectivity layer actually is.
What the TCON Does Either Way
It’s worth being precise about where the TCON sits in this decision, because it’s easy to assume rendering location changes what the TCON does. It mostly doesn’t. Whether an image arrives as a cloud-rendered bitmap or gets assembled locally from structured data, the TCON’s job starts at the same point: take a final image and drive the panel to display it — covered in full in our TCON board explainer.
Where the TCON’s capability does matter regardless of architecture is refresh efficiency. A cloud-rendered image and a locally-rendered image both still need to update the panel efficiently — redrawing only what changed rather than flashing the whole screen for a minor update. This is where MyGica’s custom TCON architecture, with arbitrary-shape partial refresh, applies equally to both rendering strategies: it doesn’t care whether the incoming image was assembled on-device or shipped pre-rendered from the cloud, only which region of that image actually changed from the last update. Choosing a rendering architecture and choosing a TCON strategy are two separate decisions, not one — a well-designed TCON layer doesn’t force you into one rendering approach over the other.
Matching Rendering to Edge Hardware
This is where system architecture choices made earlier in a project come back around. Our interface and platform guide covers MyGica’s MCU/SoC range, and the capability spread there maps directly onto which rendering approach actually makes sense:
- A platform like EPC3566, with a full Linux/Android OS and meaningfully more RAM and compute, can comfortably handle local font rendering and layout — edge rendering is a realistic option here without heroic firmware engineering.
- A lighter, RTOS-based platform like EPC-ESP32 has a real memory ceiling for this kind of work. Edge rendering is still possible for simple layouts, but complex typography or dense layouts push against the same memory constraints covered in our development pitfalls guide — where dithering, specifically, competes with everything else for a limited RAM budget.
This is actually one of the more underrated advantages of cloud-to-image rendering: it doesn’t just simplify the edge firmware, it can solve the dithering-memory problem outright by moving dithering to the server, where memory isn’t a meaningful constraint. If a lightweight MCU platform is fighting for RAM between a frame buffer and error-diffusion dithering, shipping a pre-dithered image from the cloud sidesteps that fight entirely.
Content Complexity and Format
Layout complexity is the other half of this decision, independent of hardware. A simple layout — a number, a label, a fixed logo — is cheap to render locally regardless of MCU capability. A complex layout — multiple fonts, dense information hierarchy, image assets, the kind of layout large-format signage tends to need — gets progressively more expensive to maintain as firmware logic, and progressively more sensible to centralize in the cloud instead. This is a meaningful part of why cloud-to-image rendering tends to suit larger-format e-paper, transit signage being a good example, where layout complexity is high and consistency across many units matters more than shaving bytes off each update.
Choosing an Architecture
| Factor | Favors Edge Rendering | Favors Cloud-to-Image |
|---|---|---|
| Edge hardware | Full-OS platform (e.g., EPC3566) | Lightweight RTOS platform (e.g., EPC-ESP32) |
| Content complexity | Simple, fixed layouts | Complex typography, dense layouts, image assets |
| Connectivity | Constrained (LoRaWAN, NB-IoT) | Reasonably available bandwidth |
| Fleet consistency | Less critical | High — centralizing layout avoids per-device drift |
| Dithering / grayscale handling | Edge MCU has RAM headroom | Memory-constrained MCU (push dithering to the cloud) |
FAQ
Does choosing cloud-to-image rendering mean giving up partial refresh?
No — partial refresh happens at the TCON level based on which region of the incoming image changed, independent of whether that image was rendered locally or in the cloud.
Can a deployment mix both approaches?
Yes — it’s common for simpler, frequently-updated fields (like a price or countdown) to use structured data and local rendering, while more complex, infrequently-updated visual content (a promotional graphic, a full-screen template) ships pre-rendered from the cloud.
Does cloud-to-image rendering increase battery consumption from larger data transfers?
It can, since a rendered image is larger than structured data — but for infrequently updated, layout-heavy content, the alternative (complex local rendering logic running more often, or a more capable — and more power-hungry — edge MCU) can cost more overall. The comparison needs to be made for your specific update frequency and content type, not assumed either way.
Which approach is easier to maintain across a large fleet?
Cloud-to-image rendering generally is, since layout and typography changes get made once centrally rather than requiring a firmware update pushed to every device in the field.