Why Monosnap got so slow — and the fix

The Electron tax, compounded

Monosnap didn’t start as an Electron app. When it was early in its life, a lot of the capture and editing code was native. Over time, UI components got rebuilt on top of a Chromium renderer — which made them easier to iterate on but added a large, permanent startup cost.

Electron doesn’t get lighter over time. Every year Chromium adds features, shipping more code, more memory baseline, and more complicated initialization. An app that was an acceptable 60 MB in 2019 is now a 180 MB minimum at launch, growing from there. That’s before considering the memory leak we covered on the memory leak page.

When you press Ctrl+Alt+5, Monosnap has to warm up a Chromium renderer to paint the capture overlay. On a cold app, that’s several hundred milliseconds. On a warm app that has already leaked into the hundreds of megabytes, it’s longer. By hour five of a workday, the overlay paints slowly enough that users can tell a difference.

The annotation editor is the worst offender

The post-capture editor window is almost entirely a Chromium webview. When you drop an arrow or draw a rectangle, the tool sends events through Electron’s IPC boundary to the native process and back again. That round trip is fast on a fresh process and noticeably laggy once the process is loaded down.

For users doing heavy annotation — bug reports, tutorials, docs — this adds up. Ten minutes of annotating feels like twenty.

Maxisnap: no Electron, no tax

Maxisnap’s editor is a native PyQt6 window. The annotation canvas uses QPainter directly on a QPixmap. There’s no webview, no IPC boundary between the tool logic and the rendering surface. When you drop an arrow, it appears in the next paint cycle. There is no round trip.

Cold start from tray to ready-to-capture is about a second on a typical machine. Capture-to-editor is under 200 ms. These numbers stay the same at hour 1, hour 4, hour 8, and hour 72. The app doesn’t degrade over time because there’s nothing to accumulate.