Penpot's New Rendering System  ## Metadata - Author: [[Aitor Moreno Melcón]] - Full Title: Penpot's New Rendering System - Category: #articles - Document Note: --- tags: [rendering, performance, tile-rendering] author: Aitor Moreno Melcón source: penpot.app reference: [https://penpot.app/blog/penpots-new-rendering-system/] date created: 2025-11-20 00:00 --- # 🏷️ Title: Penpot's new rendering system ## 🧭 Table of Contents - [📝 Summary](#-summary) - [📖 Main Content](#-main-content) - [🗒️ Notes](#️-notes) - [📚 References](#-references) - [🗣️ Paraphrase](#️-paraphrase) - [📰 Newsletter](#-newsletter) - [✅ Action Items](#-action-items) - [🧪 Hypotheses](#-hypotheses) - [📊 Methodology](#-methodology) - [❓ Questions](#-questions) - [🔮 Future Research](#-future-research) - [💡 Implications](#-implications) - [🧠 Learning Styles Assessment](#-learning-styles-assessment) - [📊 Accessibility Assessment](#-accessibility-assessment) - [🌍 DEIB Assessment](#-deib-assessment) - [✅ Logical Validity](#-logical-validity) - [🛡️ DARVO Analysis](#-darvo-analysis) - [🎯 Conclusion](#-conclusion) ### 🔗 References - Include links cited in or relevant to the article. ## 📝 Summary - What happened: Penpot introduced a new rendering system centered on tile rendering to improve performance on large, complex designs. - Why it matters: Keeps the canvas feeling “limitless” by respecting practical limits (CPU/GPU/memory) and rendering only what’s needed. - Key stakeholders: Penpot users, open-source contributors, frontend/rendering engineers. - Risks and tradeoffs: Cache eviction heuristics, memory budget tuning, potential artifacts at tile boundaries if not handled carefully. - Bottom line: Tiled rendering + smart caching enables smooth panning/zooming and scalability on diverse hardware. ## 📖 Main Content - Core idea: Use tile rendering to draw only visible and potentially-visible regions, caching nearby tiles and evicting distant ones when memory is full. - Context/definitions: - Tile rendering: Break the canvas into fixed-size tiles; render and cache tiles intersecting the viewport or near it. - Viewport vs. potentially-visible area: Immediate view versus a margin area likely to be needed next. - Cache budget: Fixed memory reserved for tile surfaces; evict far-away tiles first. - Uncertainties: - Exact tile size, cache eviction policy details, and GPU/CPU balancing aren’t fully specified. - Integration details with Penpot’s overall rendering pipeline beyond tiles are not elaborated here. ### 🗒️ Notes - “One of the hardest challenges… is rendering performance.” - Designs feel limitless, but computation isn’t; memory/CPU/GPU impose hard limits. - Tile rendering is “a very old concept” from games and used by browsers/GPUs. - Penpot renders: - Bright tiles = intersect viewport. - Slightly bright = potentially visible. - Dark = cached but currently not visible. - Fixed cache budget; evict farthest tiles first to keep likely-needed tiles warm. - Visualizations: viewport (magenta), shapes (yellow), tiles (cyan) to illustrate categories and caching. - Source dive: render-wasm/src/tiles.rs. - Community thread discusses moving away from heavy DOM dependence. ## 📚 References - Penpot’s new rendering system (article): https://penpot.app/blog/penpots-new-rendering-system/ - Tile renderer source (tiles.rs): https://github.com/penpot/penpot/blob/develop/render-wasm/src/tiles.rs - Community discussion on the new render engine: https://community.penpot.app/t/its-time-for-penpot-to-almost-move-away-from-the-dom/6437/37 ## 🗣️ Paraphrase - Paragraph A: Rendering complex documents smoothly is hard; tile rendering helps by focusing work on what’s visible and nearby. - Paragraph B: A fixed cache of tiles is maintained; when full, tiles farthest from the viewport are discarded first. ## 📰 Newsletter Penpot shipped a smarter renderer that makes massive canvases feel snappy. The trick? Tile rendering—an old game-dev staple now powering design workflows in the browser. If you care about performance budgets and rendering paths in design tooling, this is a crisp, practical read. For WordPress builders: apply the same mindset to admin UIs and block previews—render incrementally, cache aggressively, and prefetch the “next” view. Links: Penpot’s post, the tiles.rs source, and a community thread on moving beyond the DOM. ## ✅ Action Items #### DevRel - Talks/demos: Live perf demo comparing tiled vs. full-canvas renders; flamegraphs. - Education: Workshop on viewport-driven rendering and cache eviction heuristics. - DX: Example projects with togglable tile sizes and budgets; profiling guides. - Marketing: Case study on low-end devices; before/after metrics. - Community: Feedback survey on perceived smoothness; beta flags. #### OSPO - Governance: Document rendering module ownership and review paths. - Compliance: Third-party deps audit in render-wasm. - Security: Sandbox policies for WASM; supply-chain checks. - Inventory: SBOM for renderer components; freshness SLOs. - Support: Office hours for contributors; perf tooling standardization. - Engagement: Upstream contributions to browser/WASM perf tooling. #### Community - Maintainers: Perf budget definitions; regression gates. - Contributors: First-issue tasks around telemetry and tests. - Sponsors: Fund low-end hardware test lab; perf bounties. - Ecosystem: Cross-project perf drills and shared benchmarks. #### WordPress - Core: Perf budgets for block preview rendering. - Core Performance: Dashboard of p95/p99 interactions; CI perf gates. - Core AI: Guardrails for model-in-the-loop previews and caching. - Core Program Team: Perf retros per release; cross-team sync. - Mobile: Lazy previews; offline tile caches. - Playground: Repro perf labs; traces export. - Community: Meetup kits on perf-first UI. - Training: Lessons on incremental rendering patterns. - Marketing: Stories on “smooth by default.” - Support: Perf troubleshooting runbooks. - Design: Visual diff tools for tile artifacts. - Documentation: Examples-first perf patterns. - Photos: Guidance on responsive caching. - TV: Short explainers on rendering strategies. - Polyglots: Perf tests on non-Latin fonts. - Accessibility: Perf doesn’t break a11y; test heatmap. - Meta: API latency SLOs for preview endpoints. - CLI: Commands to profile plugin UIs. - Hosting: Telemetry for real-user perf. - Tide: Signal for UI perf hygiene. - Openverse: Incremental search result rendering. - Themes: Perf lint rules; test matrices. - Plugins: Perf checks; provenance for WASM assets. #### The WPCC - Programs: Maintainer stipends for perf triage. - Projects: Documentation sprints on perf patterns. - Funding: Milestone payouts tied to p95 wins. ### FAIR - Technical independence: Signed WASM, local provenance. - Policies: Transparent funding and sunset clauses. - Governance artifacts: Renderer module charters and scorecards. ## 🧪 Hypotheses - Tiled rendering reduces average frame render time versus full-canvas redraws. - Adding a prefetch margin lowers perceived jank during fast pans. - Evicting farthest tiles minimizes cache misses versus LRU-only. - Fixed memory budgets prevent GC thrash and improve tail latency. - Low-end GPUs benefit disproportionately from tile caches. ### 📊 Methodology - A/B builds: tiled vs. non-tiled; vary tile size and cache budget. - Metrics: FPS, p95/p99 frame time, cache hit rate, memory, time-to-first-paint after pan/zoom. - Datasets: Synthetic scenes (shapes/effects/images) and real user docs. - Devices: Low/mid/high-end CPUs/GPUs; mobile/desktop. - Analysis: Regression with interaction terms (device class × tile size). ### ❓ Questions - Optimal tile size by device class? - Best prefetch margin for mixed zoom/pan behaviors? - How to balance CPU vs. GPU work in WASM/browsers? - Artifact handling at tile boundaries with effects/compositing? ### 🔮 Future Research - Adaptive tile sizing based on scene complexity. - ML-guided prefetch from user navigation patterns. - Cross-worker parallel tile pipelines. - GPU-driven tile binning via WebGPU. ### 💡 Implications - Practice: Design tools can scale on modest hardware. - Policy: Set explicit perf budgets and CI gates. - Security: Harden WASM supply chain and sandboxing. - Education: Teach incremental rendering fundamentals. - Funding: Prioritize perf work with measurable user - Summary: One of the hardest challenges in building a design tool like Penpot is rendering performance. As designs grow in complexity, ensuring smooth performance becomes increasingly difficult. - URL: https://penpot.app/blog/penpots-new-rendering-system/ [Penpot](https://penpot.app/blog/tag/penpot/) One of the hardest challenges in building a design tool like Penpot is rendering performance. As designs grow in complexity, ensuring smooth performance becomes increasingly difficult. [](https://penpot.app/blog/author/aitor/)[Aitor Moreno Melcón](https://penpot.app/blog/author/aitor/) The image shows the title of the article in the middle , surrounded by a system of gears and pixel One of the hardest challenges in building a design tool like Penpot is **rendering performance**. As designs grow in complexity, with almost infinite possibilities, **ensuring smooth performance** becomes increasingly difficult. A document can have infinite frames, shapes, effects, fonts, images, etc. but infinity is a concept that does not exist (computationally speaking), **everything has a limit**: memory, CPU time, GPU memory and time, etc.; the idea is to allow users to create without those in mind by creating an experience that feels limitless. And that's when certain techniques are key to smooth performance and offer that feeling of limitless potential, in this post we're going to cover a key new technique used by our new render engine: **Tile rendering.** By the way, if you missed it, my colleague **Elena Torró** gave a wonderful talk about our new render engine in Penpot Fest 2025. #### Tile rendering Tile rendering is a very old concept that was mainly used to reduce the amount of memory needed to render huge scenarios in videogames using small reusable pieces called tiles. Modern browsers also use this technique to allow a extremely large amount of devices to be able to render web pages. GPUs also use this concept in a different way to allow rendering everything in parallel. In our case with a (in theory) limitless canvas, the idea is being able to deal with huge documents by rendering only those parts of the document that are visible and keep a cache of tiles that could be potentially visible. In the following example, the magenta-filled area represents the document viewport, the surrounding magenta rectangle represents the potentially visible area, the yellow rectangles represent a series of randomly generated shapes, and the cyan rectangles represent the different categories of tiles. The filled ones are tiles that are rendered classified by their visibility; the brighter ones represent the tiles that intersect with the view, the slightly brighter ones are those that are in the potentially visible area, and the darker ones are those that are rendered and cached but not visible. Some content could not be imported from the original document. [View content ↗](https://codepen.io/AzazelN28/embed/preview/emZNraB?default-tabs=js%2Cresult&height=300&host=https%3A%2F%2Fcodepen.io&slug-hash=emZNraB) Visualization of how the tile rendering and tile cache works A fixed amount of memory is reserved for tiles, so when this amount of cached tiles reaches its maximum capacity, what we do is start disposing those surfaces that are further from the view so we can guarantee that when the user moves around, at least we could keep those tiles that have a greater probability of being rendered. In the next visualization, the parts inside tiles that are visible are rendered as white, while the ones that aren't visible but kept in cache are rendered as grey, those are **kept in cache as long as possible**. Some content could not be imported from the original document. [View content ↗](https://codepen.io/AzazelN28/embed/preview/pvyjNRy?default-tabs=js%2Cresult&height=300&host=https%3A%2F%2Fcodepen.io&slug-hash=pvyjNRy) Visualization of how rendering works If you'd like to deep dive in the source code take a look at: <https://github.com/penpot/penpot/blob/develop/render-wasm/src/tiles.rs> And if you want to join the conversation about our new render engine, join our Community: <https://community.penpot.app/t/its-time-for-penpot-to-almost-move-away-from-the-dom/6437/37>, Penpot's New Rendering System, Aitor Moreno Melcón, 01kagqh9xz1nrtrrhkg7m7bmr7.