Monosnapがなぜこんなに遅くなったのか — そしてその解決策

Electronの負担、複合的に

Monosnapは’Electronアプリとして始まりませんでした。初期の頃は、キャプチャおよび編集コードの多くはネイティブでした。時間が経つにつれて、UIコンポーネントはChromiumレンダラーの上に再構築され、 — これにより反復処理は容易になりましたが、起動時に大きな永続的なコストが追加されました。

Electronは’時間が経っても軽くなりません。毎年Chromiumは機能を追加し、より多くのコード、より多くのメモリベースライン、より複雑な初期化を出荷しています。2019年には許容範囲だった60 MBのアプリは、現在では起動時に最低180 MBとなり、そこからさらに増加します。それは’私たちが メモリリークのページで取り上げたメモリリークを考慮する前の話です。.

を押すと、 Ctrl+Alt+5Monosnapはキャプチャオーバーレイを描画するためにChromiumレンダラーをウォームアップする必要があります。コールドアプリでは、それは’数百ミリ秒かかります。すでに数百メガバイトのメモリを消費している「温かい」アプリでは、さらに’長くなります。勤務時間の5時間目には、オーバーレイの描画が遅くなり、ユーザーは違いに気づくでしょう。

アノテーションエディターが最悪の犯人です

キャプチャ後のエディターウィンドウは、ほぼ完全にChromium webviewです。矢印をドロップしたり、長方形を描画したりすると、ツールはElectronの’IPC境界を介してネイティブプロセスにイベントを送信し、再び戻します。この往復は、新しいプロセスでは高速ですが、プロセスに負荷がかかると著しく遅延します。

大量のアノテーションを行うユーザーにとって — (バグレポート、チュートリアル、ドキュメントなど) — これは積み重なります。10分のアノテーションが20分のように感じられます。

Maxisnap: Electronなし、負担なし

Maxisnap’のエディターはネイティブのPyQt6ウィンドウです。アノテーションキャンバスは QPainter を直接使用します。 QPixmap。’webviewはなく、ツールロジックとレンダリングサーフェスの間にIPC境界もありません。矢印をドロップすると、次の描画サイクルで表示されます。往復処理はありません。

通常のマシンでは、トレイからのコールドスタートでキャプチャ準備完了まで約1秒です。キャプチャからエディターまでは200 ms未満です。これらの数値は、1時間後、4時間後、8時間後、72時間後でも同じです。アプリは’時間が経っても劣化しません。なぜなら’蓄積されるものがないからです。