Electron is niet de bottleneck van je schermrecorder

Kortom — Electron gebruikt aantoonbaar meer geheugen, maar hoeft opname en export niet merkbaar te vertragen.

Op onze M4 Mac mini namen zowel een native ScreenCaptureKit-recorder als dezelfde recorder vanuit Electron 4K-video op met respectievelijk 57,70 en 57,53 fps. Een 4K-bewerkingsshader kostte bij P95 1,62 ms per frame met rechtstreeks Metal en 1,90 ms via Electrons WebGL-naar-Metal-pad. Een gecontroleerde 1080p H.264-export liep via native VideoToolbox op 7,54× realtime en via Electrons WebCodecs-pad op 7,46× realtime.

Het verschil was niet nul. Het zat alleen niet waar het gebruikelijke argument het plaatst.

Het duidelijke nadeel van Electron was het geheugengebruik: 45 MB voor de rechtstreeks aangestuurde native opnamehost tegenover 94 MB voor de ondertekende Electron/Node-host, nog zonder Chromium-renderer. Een verpakte Tight Studio-sessie stabiliseerde in deze test rond 744–749 MB. Die afweging moeten we eerlijk benoemen. Ze bewijst niet dat opgenomen frames via een webpagina moeten lopen of dat export op softwarecodering moet terugvallen.

We bouwen Tight Studio met Electron en hebben dus belang bij deze vraag. Daarom hebben we de benchmark gecontroleerd en reproduceerbaar opgezet, en delen we zowel de resultaten waarin Electron slechter presteert als die waarin het goed presteert.

"Native vs Electron" is het verkeerde abstractieniveau

Een desktopapp bestaat niet uit één uitvoeringslaag.

Electron biedt een Chromium-renderer, een Node.js-hoofdproces en een applicatieschil met meerdere processen. Het ondersteunt ook native modules. De documentatie van Electron vermeldt expliciet dat een app native code kan gebruiken voor platform-API’s en prestatiekritisch werk.

Dat betekent dat een Electron-schermrecorder op minstens twee heel verschillende manieren kan worden gebouwd:

1. Leg frames vast, combineer, kopieer en codeer ze via JavaScript en browserinterfaces.
2. Gebruik Electron voor product-UI en orkestratie terwijl ScreenCaptureKit, AVFoundation, Metal, VideoToolbox, of een andere native media-engine het kritieke pad beheert.

Die apps gebruiken hetzelfde framework, maar niet dezelfde prestatiearchitectuur.

Electron vormt al de basis van veeleisende desktopapps

Deze architectuur is niet ongebruikelijk. De huidige macOS-distributies van Codex en Claude gebruiken Electron. Op de machine die voor dit artikel is gebruikt, verklaart Codex 26.825.41651 ElectronAsarIntegrity ervoor app.asar pakket, terwijl Claude 1.26832.0 beide verzendt Electron Framework.framework en app.asar.

De eigen documentatie van Electron noemt ook Visual Studio Code, Figma, Docker Desktop, Loom, Canva, Notion, 1Password, Slack, Discord en Signal als producten die met het framework zijn gebouwd. Ze bestrijken codebewerking en debugging, collaboratieve graphics, containerbeheer, schermopname, credentialbeheer, berichten, spraak en video, en AI-workflows.

Die lijst is geen prestatiebenchmark en bewijst niet dat elke Electron-app efficiënt is. Ze maakt wel het architectuurpunt duidelijk: als je Electron voor de desktopinterface kiest, hoeft die interface niet elke zware bewerking zelf uit te voeren. Native modules, GPU-processen, lokale services en externe systemen kunnen het specialistische werk overnemen.

Je kunt de macOS-bundelcontrole reproduceren zonder speciale gereedschappen. Kies in Finder Toon pakketinhoud, controleer vervolgens Contents/Info.plist, Contents/Resources/app.asar, en Contents/Frameworks/.

Tight Studio gebruikt het tweede model. Op macOS legt een Swift-module de schermframes vast met ScreenCaptureKit en schrijft AVAssetWriter ze weg. De opname maakt geen omweg via de DOM, React of een Chromium-canvas. Tijdens bewerking en export doen GPU-compositing en hardwarecodec-API’s het zware werk; JavaScript coördineert de pipeline.

Apple beschrijft ScreenCaptureKit als zijn high-performance API voor frame- en audiovaslegging. Electron voorkomt niet dat een app deze aanroept. Een native module kan hetzelfde framework aanroepen, en dezelfde CMSampleBuffer objecten, en geef ze aan hetzelfde systeemencoder.

Wat we hebben gebenchmarkt

We hebben bewust geen twee eindproducten vergeleken. De ene app rendert misschien ondertitels, cursorbewegingen, een camera-uitsnede en vijf overlays, terwijl de andere alleen de oorspronkelijke opname opnieuw muxt. Het snellere resultaat zou ons vrijwel niets over Swift of Electron vertellen.

In plaats daarvan hielden we de werklast constant:

• Machine: Apple M4 Mac mini, 10-core CPU, 10-core GPU, 16 GB geheugen, macOS 26.5.2.
• Opnemen: de exact dezelfde verpakte native capture-engine, eenmaal uitgevoerd vanuit zijn directe Swift CLI en eenmaal vanuit Tight Studio’s ondertekende Electron/Node uitvoerbare bestand. Beide namen hetzelfde geanimeerde 3840×2160 display op bij een 60 fps doel.
• Bewerking: dezelfde procedurele achtergrond, afgeronde kaart, raster, schaduw, en geanimeerde cursor shader bij 3840×2160. Native gebruikte Metal; Electron gebruikte WebGL 2 via ANGLE’s Metal-renderer. Elk frame had een synchronisatiegrens zodat een verborgen canvas het werk niet kon laten verdwijnen.
• Exporteren: 300 frames op 1920×1080, 30 fps, H.264 en een doelbitrate van 12 Mbps. Native gebruikte Metal en VideoToolbox. Electron gebruikte WebGL en WebCodecs, met hardwareversnelling ingeschakeld.
• Uitvoeringen: drie per pad. De tabel rapporteert medianen.

We nemen geen batterijresultaat op. Dit was een Mac mini; voor een geloofwaardige uitspraak over batterijgebruik is een langere, gecontroleerde MacBook-test nodig.

Resultaten

Fase	Direct native	Electron/hybrid	Elektron verschil
4K opname-uitvoersnelheid	57.70 fps	57.53 fps	-0.29%
Opnemen host CPU	7.06%	6.98%	-0.09 punten
Opnemen OS-service CPU	31.34%	32.76%	+1.42 punten
Opnemen piekgeheugen van host	45.36 MB	94.39 MB	+49.03 MB
4K bewerk shader doorvoer	684.23 fps	593.77 fps	-13.22%
P95-frametijd van de 4K-bewerkingsshader	1.62 ms	1.90 ms	+0.28 ms
1080p exportdoorvoer	226.10 fps	223.78 fps	-1.02%
1080p exportsnelheid	7.54x realtime	7.46x realtime	-1.02%

Dit zijn korte, gecontroleerde tests op één machine. Ze bepalen wat mogelijk is met deze architecturen; ze zijn geen belofte dat elke Electron-app zo efficiënt zal zijn.

Opnemen: Electron hoeft geen enkel frame aan te raken

De opnameresultaten zijn vrijwel gelijk omdat beide paden op de beslissende punten hetzelfde zijn.

ScreenCaptureKit levert de frames. AVAssetWriter en de systeemcodecs coderen ze. Electron vraagt de native recorder alleen om te starten, stoppen, pauzeren en hervatten. Het ontvangt geen 4K-pixelbuffers via IPC en codeert ze niet in JavaScript.

Over de drie runs behaalde native een mediaan van 57,70 fps en de Electron-host 57,53 fps: een verschil van 0,29%. Het mediane CPU-gebruik van de recorder was 7,06% voor native en 6,98% voor de Electron-host. De macOS-opnameservices gebruikten gemiddeld respectievelijk 31,34% en 32,76%.

Het frame-per-seconde resultaat is het belangrijke. De kleine CPU-omkering is gewone run-tot-run ruis, geen bewijs dat Electron op de een of andere manier ScreenCaptureKit versnelt.

Er is één testdetail dat we moeten toelichten. macOS verleent toestemming voor schermopname aan een ondertekende app-identiteit. Onze Electron-ontwikkelbuild had die toestemming niet. Daarom gebruikten we voor de Electron-opnamerun het ondertekende uitvoerbare bestand van Tight Studio in de Node-compatibele modus van Electron. Daarmee isoleren we de native brug, maar ontbreekt de Chromium-renderer. We hebben de verpakte applicatieschil apart gemeten, in plaats van de host van 94 MB stilzwijgend als volledige Electron-app te presenteren.

Bewerken: vertaald naar Metal is nog altijd Metal

JavaScript biedt Apple’s Metal API niet direct aan. Dat feit wordt soms uitgerekt tot een veel bredere bewering: dat Electron geen Metal-ondersteunde GPU-weergave kan gebruiken.

Op macOS biedt ANGLE een Metal-backend voor OpenGL ES, wat Chromium kan gebruiken onder WebGL. Onze Electron-benchmark identificeerde de renderer als ANGLE Metal Renderer: Apple M4.

Metal rechtstreeks aansturen was sneller. De mediane native run renderde 684 frames per seconde; Electron renderde er 594, een verschil in doorvoer van 13%. De P95-frametijd steeg van 1,62 naar 1,90 ms.

Dat is meetbare overhead. Het gaat om 0,28 ms binnen een framebudget van 16,67 ms bij 60 fps.

Echte editors doen natuurlijk meer dan één shader uitvoeren. Ze decoderen video, uploaden of importeren textures, renderen tekst, berekenen animatiestanden en verwerken invoer. Een onzorgvuldige implementatie kan de resterende ruimte verspillen aan kopieën, geheugentoewijzingen, synchrone IPC of React-werk. Maar de browsercompositor is niet automatisch een softwarerenderer, en WebGL op een Mac bewijst niet dat de GPU wordt omzeild.

Wanneer een WebGL- of WebGPU-pad niet genoeg is, staat Electron nog steeds een native Metal-module toe. De architectuur kan zijn nooduitgang per subsystem kiezen.

Exporteren: de hardware-encoder maakt het niet uit welke knop hem startte

VideoToolbox is Apples low-levelinterface voor hardwarematige encoders en decoders. Chromium heeft op macOS een VideoToolbox-backend voor encoders, en met WebCodecs kunnen apps een voorkeur voor hardwareversnelling aangeven.

Tijdens onze native run bevestigde VideoToolbox dat hardwarecodering werd gebruikt. De Electron-run vroeg via WebCodecs om hardwareversnelling. WebCodecs toont de naam van de geselecteerde encoder niet, dus we kunnen de keuze van Electron niet op API-niveau bewijzen. De prestaties en uitvoer passen wel bij het hardwarepad: native codeerde 300 frames in mediaan 1.327 seconden; Electron deed er 1.341 seconden over. De bestandsgrootte verschilde minder dan 1%.

Dat komt neer op 7.54x versus 7.46x in realtime—een 1% verschil.

Dat betekent niet dat elke Electron-exporter snel is. Export wordt trager wanneer een app:

• leest pixels terug van de GPU voor elk frame;
• kopieert volledige frames via JavaScript of IPC;
• codeert in software;
• serialiseert decodeer-, render-, audio- en encode-stadia onnodig;
• houdt de hele uitvoer in het geheugen in plaats van deze te streamen;
• gebruikt de UI-thread als de render-werker.

Dat zijn pijplijnkeuzes, geen eisen opgelegd door Electron.

Een echte Tight Studio-export

Microbenchmarks laten zien waar overhead ontstaat. Een producttest laat zien of de volledige pipeline in de praktijk bruikbaar is.

We voerden ook de bestaande exportregressietest met vijf clips van Tight Studio drie keer uit. De tijdlijn van 112 seconden test per clip decodering, GPU-rendering, audio, codering, samenvoeging en muxing op 1440×1080. De exporttijden waren 81,54, 80,94 en 81,28 seconden. De mediaan was 81,28 seconden, oftewel 1,38× realtime.

Het gegenereerde bestand duurde 112,36 seconden, draaide op ongeveer 30 fps en bevatte H.264-video met AAC-audio. Deze testopstelling levert geen universele exportsnelheid op — bronmedia en effecten maken verschil — maar toont wel een volledige Electron-app die in een reproduceerbare repositorytest sneller dan realtime exporteert.

Het deel dat Electron echt verliest: geheugen

Electron bevat een browserruntime met meerdere processen. Dat kost geheugen.

De directe native opname-host piekte bij 45 MB RSS. De gesigneerde Electron/Node-host piekte bij 94 MB. Onze minimale Electron-bewerkingsprocesboom was ongeveer 360 MB, en de exportprocesboom was ongeveer 394 MB. Een verpakte Tight Studio-sessie met een nieuw profiel bleef rond 744–749 MB in deze specifieke app-toestand.

Dat laatste nummer is geen wet van Electron, en het is geen vergelijking met een native app. Het is een herinnering om geen minimale testomgeving te gebruiken als marketingcamouflage.

Op systemen met weinig ruimte kan geheugengebruik belangrijk zijn. Het kan geheugendruk veroorzaken, meer swap nodig maken en indirect energie kosten. Maar toegewezen RAM is niet hetzelfde als CPU-gebruik tijdens opname, verloren frames, GPU-frametijd of encoderdoorvoer. Wie de ene waarde als maatstaf voor alle andere gebruikt, trekt verkeerde technische conclusies.

Het praktische doel is niet ‘geen geheugen voor Chromium gebruiken’. Het gaat erom de browserruntime buiten de kritieke paden voor onbewerkte frames te houden, mediaobjecten tijdig te sluiten, buffers te begrenzen, uitvoer te streamen en geen werk te doen wanneer de app niets doet.

Een betere manier om een schermrecorder te evalueren

Vraag wat elk subsysteem daadwerkelijk doet:

• Welke API neemt het scherm op?
• Waar worden frames samengesteld?
• Is de GPU-backend hardwarematig versneld?
• Welke encoder-implementatie is geselecteerd?
• Hoe vaak wordt een volledig frame gekopieerd?
• Gaat pixeldata over IPC of JavaScript-grenzen?
• Kan de editor 60 fps behouden bij de doelresolutie?
• Wat is de exporttijd per seconde uitvoer?
• Wat zijn bij dezelfde werklast de resultaten voor CPU-gebruik, geheugen, verloren frames, energieverbruik en temperatuur?

"Native" en "Electron" zijn nuttige implementatiedetails. Het zijn zwakke benchmarkresultaten.

De conclusie

Een volledig native app heeft de laagst mogelijke overhead voor de applicatieschil en de meest directe toegang tot platform-API’s. Als twee teams even goed geoptimaliseerde pipelines met dezelfde functies bouwen, behoudt native een voordeel — vooral in geheugengebruik en de fijnste GPU-aansturing.

Een Electron-app hoeft zijn media-engine echter niet op DOM-nodes en JavaScript-lussen te bouwen. De app kan opnemen via ScreenCaptureKit, beelden samenstellen met GPU-API’s die Metal gebruiken, coderen met de hardwarematige media-engine en prestatiekritisch werk onderbrengen in native modules of workers.

Onze metingen lieten een verschil van 0,29% in opnameframerate zien, 13% in de doorvoer van een synthetische 4K-shader en 1% bij gecontroleerde export. Het verschil in geheugengebruik was wel groot. Zo ziet de afweging er eerlijk gezegd uit.

Het framework bepaalt de uitgangspunten. De pipeline bepaalt de prestaties.

Bronnen en reproductie

• Apple: ScreenCaptureKit
• Apple: VideoToolbox
• Electron: Native code en Electron
• Electron: Procesmodel
• Electron: Waarom Electron en voorbeelden van productie-apps
• HOEK: Metal-backendondersteuning
• Chromium: macOS VideoToolbox-encoder
• W3C: WebCodecs hardwareversnelling

Het benchmarkframework, de ruwe looptabel, de toestemmingsvoorbehoud en de interpretatielimieten worden voorbereid voor een zelfstandige publieke release. We zullen de repositorylink hier toevoegen zodra het pakket kan worden gekloond en onafhankelijk kan worden uitgevoerd. Extra Apple-siliconmachines en een gecontroleerde MacBook-stroomtest zouden deze resultaten kunnen uitbreiden, maar ze zijn niet opgenomen in de claims hierboven.