Enregistreurs d'écran natifs vs Electron : performance, batterie et pourquoi c'est important

Electron est un framework qui permet aux développeurs de créer des applications de bureau avec des technologies web — HTML, CSS et JavaScript. Il fonctionne en intégrant Chromium (le moteur de navigateur derrière Google Chrome) à l'intérieur de l'application.

Slack, VS Code, Discord et Figma sont toutes des applications Electron. Pour de nombreux types de logiciels, Electron est un choix raisonnable. Il permet aux équipes de publier sur Mac, Windows et Linux à partir d'une seule base de code.

Mais l'enregistrement d'écran est l'un des pires cas d'utilisation pour Electron.

Quand vous enregistrez votre écran, l'application d'enregistrement fonctionne en parallèle de tout le reste sur votre Mac. Elle doit capturer des images, traiter l'audio et encoder la vidéo — tout en restant discrète. Plus l'enregistreur utilise de ressources, plus il interfère avec ce que vous enregistrez.

C'est là que la différence d'architecture entre natif et Electron devient très visible.

Ce qu'Electron ajoute

Quand vous lancez une application Electron, vous lancez une instance complète du navigateur Chromium. Cela signifie :

• Surcharge mémoire. Chromium commence à environ 150 à 200 Mo de mémoire avant que l'application ne fasse quoi que ce soit. Une application macOS native démarre à une fraction de cela — typiquement 30 à 80 Mo.
• Utilisation CPU. Le moteur du navigateur exécute son propre pipeline de rendu, ramasse-miettes et runtime JavaScript. Ceux-ci sont toujours actifs, même au repos.
• Pas d'accès direct à Metal. Les applications Electron peuvent utiliser WebGL, mais elles n'ont pas le même accès GPU de bas niveau qu'une application native Swift à travers Metal. Cela limite le rendu et la composition accélérés par le matériel.
• Pas d'accès direct à VideoToolbox. L'encodeur vidéo matériel du système est accessible via le framework VideoToolbox d'Apple. Les applications natives l'appellent directement. Les applications Electron ont besoin de ponts, de wrappers, ou se rabattent sur l'encodage logiciel.

Pour un éditeur de texte ou une application de chat, cette surcharge est tolérable. Pour un enregistreur d'écran qui doit être léger, rapide et efficace en termes de matériel, c'est un désavantage structurel.

Comment cela affecte l'enregistrement d'écran

Pendant l'enregistrement

Un enregistreur natif utilise ScreenCaptureKit — l'API d'Apple pour la capture d'écran — directement. Les images vont de l'écran à l'encodeur avec un minimum de surcharge.

Un enregistreur basé sur Electron peut appeler ScreenCaptureKit, mais les images passent par le pipeline de rendu du navigateur. Le traitement JavaScript supplémentaire, les couches de pont et les copies mémoire ajoutent de la latence et de la consommation de ressources.

Le résultat pratique : un enregistreur natif utilise typiquement moins de CPU pendant l'enregistrement, génère moins de chaleur et est moins susceptible de provoquer des pertes d'images dans l'application enregistrée.

Pendant le montage

Le montage vidéo implique le rendu d'aperçus — application du zoom, des arrière-plans, des superpositions et des sous-titres à chaque image. Une application native les rend avec Metal, utilisant directement le GPU pour la composition.

Une application Electron rend à travers le compositeur du navigateur, qui est conçu pour les mises en page web, pas pour la composition d'images vidéo. Le rendu de l'aperçu est plus lent et moins fluide.

Pendant l'exportation

C'est là que la différence est la plus spectaculaire.

Une application macOS native sur Apple Silicon utilise :

• Metal pour la composition d'effets (zoom, arrière-plans, superpositions).
• VideoToolbox pour l'encodage accéléré par le matériel via le Media Engine dédié.
• Mémoire unifiée pour le traitement des images vidéo sans copie entre CPU et GPU.

Une application Electron utilise typiquement :

• Rendu basé sur le navigateur pour la composition (plus lent que Metal).
• Encodage logiciel ou encodage matériel via des ponts (moins direct que VideoToolbox).
• Copies mémoire entre le runtime JavaScript et l'encodeur système.

Le résultat : un enregistreur natif peut exporter un enregistrement de 5 minutes en secondes. Un enregistreur basé sur Electron peut prendre plusieurs minutes pour le même enregistrement.

Batterie et thermique

Sur un MacBook, cela compte plus que sur un ordinateur de bureau.

L'enregistrement d'écran se fait souvent sur des portables — enregistrement d'une présentation, d'une démo en déplacement ou d'une leçon de cours dans un café. L'application d'enregistrement fonctionne en parallèle de l'application enregistrée, du navigateur et de tout ce qui est ouvert.

Une application native utilise moins de CPU et moins de mémoire, ce qui signifie :

• Moins de consommation de batterie pendant l'enregistrement.
• Moins de bruit de ventilateur dû à la chaleur.
• Moins de throttling thermique, qui peut affecter les performances des autres applications.

Une application Electron ajoute la surcharge de Chromium, qui augmente la consommation d'énergie même quand l'enregistrement est au repos.

Pour un clip de 5 minutes, la différence est faible. Pour une leçon de cours de 30 minutes enregistrée sur batterie, c'est notable.

Le compromis multiplateforme

Electron existe parce que le multiplateforme a de la valeur. Construire une application qui fonctionne sur Mac, Windows et Linux est plus rapide et moins cher que de construire trois applications natives.

Pour l'enregistrement d'écran, le compromis est :

• Electron : Une base de code, toutes les plateformes, mais avec des pénalités de performance et de ressources sur chacune.
• Natif : Meilleures performances et intégration sur une plateforme, mais Mac uniquement (ou une application séparée pour chaque plateforme).

Si vous avez besoin d'un enregistreur d'écran qui fonctionne aussi sur Windows et Linux, les options basées sur Electron ou OBS (C++ multiplateforme) peuvent être le choix pragmatique.

Si vous enregistrez sur un Mac et voulez les meilleures performances, autonomie et vitesse d'exportation, une application native construite sur Swift, Metal et ScreenCaptureKit surpassera une alternative Electron.

Quelle architecture utilisent les enregistreurs d'écran

Natif macOS (Swift / Metal) :

• ScreenKite
• Screen Studio

Electron / basé sur le web :

• Kap
• ScreenCharm

Multiplateforme (C++ / Qt) :

• OBS Studio

Cloud / basé sur le navigateur :

• Loom
• Tella

Où se situe ScreenKite

ScreenKite est une application macOS native construite en Swift. Elle utilise :

• ScreenCaptureKit pour la capture d'écran.
• Metal pour la composition et le rendu accélérés par GPU.
• VideoToolbox pour l'encodage accéléré par le matériel sur Apple Silicon.
• Mémoire unifiée pour le traitement des images sans copie.

Le résultat est une faible utilisation des ressources pendant l'enregistrement, des aperçus de montage fluides et des exportations rapides. Sur Apple Silicon, un enregistrement typique s'exporte en secondes.

ScreenKite est gratuit, sans filigrane et sans limite de durée.

Conclusion

L'architecture d'une application d'enregistrement d'écran détermine son plafond de performance. Un enregistreur basé sur Electron ne peut jamais être aussi léger qu'un natif car il porte la surcharge d'un moteur de navigateur.

Pour les personnes qui enregistrent régulièrement sur un Mac — tutoriels, démos, cours, démonstrations — un enregistreur natif utilise moins de batterie, chauffe moins, monte plus vite et exporte radicalement plus rapidement.

Si vous voulez voir la différence, essayez ScreenKite. C'est gratuit, et la vitesse d'exportation seule suffit à convaincre.