From ff9b9661095311d7f31aaeb5c91fd4dc8a5d70dd Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Gerg=C5=91=20T=C3=B6rcsv=C3=A1ri?= Date: Tue, 30 Jun 2026 08:41:30 +0200 Subject: [PATCH] docs(site): dev blog updates (w26 + webgl-porting post) Co-Authored-By: Claude Opus 4.8 (1M context) --- site/src/content/blog/devblog-2026-w26.mdx | 33 ++++++++++++++++--- ...orting-kicad-graphics-to-webgl-in-2026.mdx | 19 ++++++----- 2 files changed, 39 insertions(+), 13 deletions(-) diff --git a/site/src/content/blog/devblog-2026-w26.mdx b/site/src/content/blog/devblog-2026-w26.mdx index cfaad6d..65dbcb0 100644 --- a/site/src/content/blog/devblog-2026-w26.mdx +++ b/site/src/content/blog/devblog-2026-w26.mdx @@ -7,11 +7,36 @@ pubDate: 2026-07-29 # History so far -The initial commit of the web assembly port of KiCad was in 2025. november. At that time KiCad was at version 9.99.0. -From that time mostly Viktor and Claude played with it, and until 2026. may, it was only a pet project. +The initial commit of the web assembly port of KiCad was in November 2025. At that time KiCad was at version 9.99.0. +Mostly Viktor and Claude played with it, and until May 2026, it was only a pet project. -From 2026 juni, we started to work on it more seriously, we started to make all the tools build and open up +From June 2026, we started to work on it more seriously, we started to make all the tools build and open up (pcb-new was already loading up, we added calculator, eeschema, gerbview, symbol-editor and footprint-editor). +We started to build a webapp around it (with projects, upload, download). We played with ydoc so that multiple people can work on the same project at the same time. Libs were an another pain point, and ofc asyncify, CI, threads, random freezes get fixed as we started to test it. +We did a wxwidgets port for the web, and we made the 3d viewer mostly work too. + +# Rebase +As I said the fork started on Kicad 9.99, and this weeks biggest effort was to move it to the current main: 10.0.4 +The rebase alone was a huge work. It broke a lot of things, like some of the 3d viewer code was rewritten on upstream. Some of the lib loading code was rewritten also, and a single build is still about 1hr, just to start the e2e tests that sometimes broke. +We also worked on the CI, to make the early releases more consistent. + +# UI/UX/Standalone features +A more noticeable work was done within the standalone/demo version of the app. We added github version/link to the demo page. +Also, the page get an idb backed folder, so you can upload your project to the browser, open and modify it, and download it back. + +We added a file browser into the project part, instead of a file list ;) + +# Libs +KiCad has a lot of symbols and footprints. We worked on a way to upload them to R2, and be able to download them while the app loads. +These are cached to local idb, so net traffic is reduced, and the app loads faster. + +Do you know what is the difference between loading 6 symbol lib vs 222? About 6 minutes. So we started to work on a better lib loading mechanism. +Most of it is still work in progress, but at least we can now add footprints and symbols, even if its really really really slow to open up the add symbols/add footprint dialog at first. + +# What's next +All of those was a work of two devs. Our third dev, Viktor, is working on some asyncify/errorhandling/multithreading magic, that reduces our apps size, and we hope it will make it faster. +We will work on the lib loading too, its a slow mvp right now, we should make it faster, or at least pinpoint why its slow right now. +We also have a lot of random bugs with wxwidgets event handling, some dialogs are not closeable, 3d model loading, app interactions (schema -> pcb sync), these will be a main topics this week. # Notes -We will try to keep writing weekly at the beginning of every week, so you can read what we are doing, and what are the problems we are facing.author +We will try to keep writing weekly at the beginning of every week, so you can read what we are doing, and what are the problems we are facing. Stay tuned! diff --git a/site/src/content/blog/porting-kicad-graphics-to-webgl-in-2026.mdx b/site/src/content/blog/porting-kicad-graphics-to-webgl-in-2026.mdx index baa7d1b..38bb1d9 100644 --- a/site/src/content/blog/porting-kicad-graphics-to-webgl-in-2026.mdx +++ b/site/src/content/blog/porting-kicad-graphics-to-webgl-in-2026.mdx @@ -1,6 +1,7 @@ --- title: "Porting KiCad's Graphics to WebGL in 2026" description: "How to make KiCad run in a browser pt. 1. Check the demo!" +author: Viktor Váczi pubDate: 2026-06-18 --- @@ -26,22 +27,22 @@ the [tiny_tapeout](https://tinytapeout.com/) demo -- entirely client-side. First I just wanted KiCad to build with a WASM target. It took a while, thankfully I've found https://github.com/ahilss/wxWidgets-wasm, a wxWidgets port for the web for an old version. -I've used that port as a starting point, but it missed a lot of features. After multiple lines of find-whats-missing and a lot of e2e tests with a lot of screenshots -I had a working~ish wxWidgets port, a good start. +I've used that port as a starting point, but it missed a lot of features. After multiple lines of "Claude! Find whats missing!" and a lot of e2e tests with a lot of screenshots +I had a working~ish wxWidgets port, as a good start. -Then it lot of corner cutting, lot of shimming things away that I wanted to work to make KiCad build. The first time the welcome dialog loaded I was happy, very happy, even though -clicks did nothing. +Then after a lot of corner cutting, even more "shimming things away" because I wanted to make KiCad to build; the first time the welcome dialog loaded I was happy, very happy (even though +clicks did nothing). Then when I got through that eventually KiCad loaded up. It was horribly slow. -I had two main sources of errors: Asyncify and the OpenGL `-sLEGACY_GL_EMULATION` that made it possible to run OpenGL apps on the web. -Asyncify is a huge error source on its own, I wanted to get rid of all OpenGL errors ( and get some speed if possible ), so I have a chance to debug them. +I had two major sources of errors: Asyncify and the OpenGL `-sLEGACY_GL_EMULATION`, which lets OpenGL apps run on the web. +Asyncify alone introduced a lot of instability, so I decided to get rid of all OpenGL errors first ( and hopefully gain some speed ), to make debugging manageable. The errors were an infinite loop of Emulation and WebGL sprinkled with some Asyncify interplay. I had no other option. # Let's rewrite to WebGL! -Thankfully KiCad has a Graphics Abstraction Layer ( GAL ). There's already an alternative CPU renderer, an OpenGL one, let's do a WebGL one then! -I don't know OpenGL but there's Claude Code. So: the core idea was to create WebGL and native test apps that check each GAL feature, compare the screenshots to double check. +Thankfully KiCad has a Graphics Abstraction Layer ( GAL ). There's already an alternative CPU renderer, an OpenGL one, so I "just" needed to write a WebGL one! +I don't familiar with OpenGL but there's Claude Code. So: the core idea was to create WebGL and native test apps. Both check each GAL feature, and compare the screenshots to double check. For the native GAL test apps I had to pull the headers inside KiCad from my test code, it needed a few shims ( KiCad usually brings the kitchen sink too ), but in the end worked. At first I wanted to do byte-to-byte comparison but it is not possible ( AFAIK ), @@ -52,7 +53,7 @@ Here are two scenarios straight out of that regression suite -- the same GAL cal So in the end I relied on asking Claude to check the screenshots, prodding, checking again, but in the end I got two screenshots folders that looked the same. -Claude back then wasn't that good at understanding screenshots, sometimes LGTM'd totally black things, couldn't see colors, but it was still helpful. +At that time Claude wasn't that good at understanding screenshots. Sometimes LGTM'd totally black things, couldn't see colors, etc., but in general it was still helpful. # Moment of truth And then I wired up my new WebGL GAL into KiCad and... It worked! And it was fast.