Webアプリケーションに基づいたWebデザイナーツールの開発（Figma）。 翻訳

設計ツールの将来に対する私たちの理解は、ツールとコンテンツに簡単にアクセスできるようにすることです。



そのため、コマンドラインインターフェイスデザインツールであるFigmaを、Webアプリケーションとして配布されるクラウドサービスとして作成しました。



Figmaを作成することを決めたとき、それが深刻な課題になることを知っていました。

真の成功を収めるには、専門家に受け入れられ、どの環境でも同等に機能する高精度の編集ツールを提供する必要があります。

結果への道は非常に困難でした。 その結果、実際にブラウザー内にブラウザーを作成しました。

このタスクの難しさの理由は、Webが汎用コンピューティングプラットフォームとして作成されていないことです。 Webは、ドキュメント指向のテクノロジーとして始まり、アプリケーション開発のために多くの優れたものが追加されました。

これは通常、あらゆるものを実装するために使用できる汎用プリミティブを提供するのではなく、かなり狭い焦点を持つ特定のAPIの形式でした。



いくつかの例：

• CSSは、多数の優れたテキストレンダリング/レイアウトアルゴリズムを提供しますが、それらをカスタマイズしたり、ブラウザーが別のアルゴリズムの一部としてテキストレイアウトアルゴリズムを使用した結果を取得したりすることはできません。
• すべてのブラウザーは高性能 GPUリンカーを提供しますが、Web環境ではレンダリングアルゴリズムに固執し、リンカーの動作を変更してパフォーマンスの最適化や特別なブレンドモードを追加する方法はありません。
• ブラウザには、ハードウェアを使用してUIストリームの外部で非同期にデコードする高度に最適化された イメージ デコーダーが組み込まれていますが、たとえば、 EXIFの向きを考慮したり、drawImageの使用時に誤った色空間の設定を防止したりできるパラメーターをデコーダーに渡すAPIはありませんgetImageData。

Webに共通のプリミティブがないという状況は変わり始めており、ブラウザーエンジンをバイパスしてハードウェアを直接操作するツールを開発者に提供するWebGLやasm.jsなどのテクノロジーがあります。 これは、最終的に高性能なWebベースのグラフィカルアプリケーションを現実的かつ実用的なものにする征服です。 開発者は、必要な機能がブラウザに実装されるまで待つ必要がなくなり、独自にそのような機能を作成できます！

Emscripten

エディターはC ++で記述されており、 emscriptenクロスコンパイラーを使用してJavaScriptでクロスコンパイルされています。 emscriptenコンパイラは、JavaScript JITコンパイラから予測可能でコンパクトなマシンコードを取得できる最新のすべてのブラウザでサポートされているJavaScriptのサブセットであるasm.jsを対象としています。



このアプローチにはいくつかの利点があります。

• メモリ構造を完全に制御し、JavaScriptの64ビットの倍精度の代わりに、コンパクトな32ビットの浮動小数点数または必要に応じてバイトを使用できます。 これは、大量のデータを使用する当社のようなアプリケーションにとって非常に重要です。
• 生成されたコードはメモリの割り当てを完全に制御します。これにより、毎秒60フレームでUIレンダリングを取得するタスクが大幅に簡素化され、ガベージコレクションによる一時停止が回避されます。 すべてのC ++オブジェクトは、事前に割り当てられた型付き配列の予約範囲に配置されるため、ここでのJavaScriptガベージコレクターとは何の関係もありません。
• 生成されたコードは、高度なLLVMコンパイラを使用して事前に最適化されます。 これをC ++テンプレートの特殊化と組み合わせると、ネイティブコードよりも最大2倍遅い非常に効率的なコードが得られます。
• また、asm.jsコードに非最適化ポイントがないことも保証されているため、JITコンパイラーはAoTコンパイルを実行し、予測可能なパフォーマンスを提供できます。 通常のJavaScriptコードはJITコンパイラのヒューリスティックアルゴリズムを通過するため、同じコードを連続して実行するとパフォーマンスが大幅に異なる場合があります。

emscriptenが完璧であることを意味するものではありません。 新しいたわごとのように、途中でプラグがありました。 私たちにとっての問題の1つは、一部のブラウザー構成では、emscriptenアドレス空間全体を含む巨大な型付き配列に、広範囲の連続アドレス空間を割り当てることができなかったことです。 最悪のケースは32ビットChrome for Windowsで 、これは256MBの型付き配列でさえ割り当てられないことがありました。 ASLR断片化アドレススペース。 それ以来、すでに修正されています。



役立つもう1つの機能は、画像やジオメトリックオブジェクトのバッファなど、ヒープからものを削除するためのハンドルの大きなリソースの使用です。 内部のIndirectBuffer APIを作成し（ ここで開きました ）、外部の型付き配列を参照し、C ++で使用できるようにします。 メインヒープから大きなオブジェクトを削除すると、長時間再生セッションのメモリフラグメンテーションの問題が軽減され、32ビットブラウザーでより制限されたアドレススペースを使用できるようになり、64ビットブラウザーでの型付き配列のサイズの31ビット制限を克服できるようになります。



現在、asm.jsはすでに非常によくサポートされていますが、たくさんのクールなものが登場します。

WebAssemblyは、asm.jsコードのバイナリ形式を実装して、すべての主要なブラウザーが参加する解析時間を大幅に短縮する試みです。 現在、マルチスレッドの唯一の形式はメッセージングWebワーカーの使用ですが、 共通の型付き配列の仕様（途中）により、共有メモリを使用したマルチスレッドが現実のものになります。

レンダリング

独自のレンダリングエンジンを作成して、すべてのプラットフォームでコンテンツが迅速かつ均一にレンダリングされるようにしました。 ブラウザには優れたグラフィックメカニズムがあり、最初は新しいレンダリングエンジンを作成する代わりに、ブラウザを使用しようとしました。 ブラウザのレンダリングツリーにアクセスするための低レベルAPIがない場合、利用可能なオプションはHTML、SVG、または2Dキャンバスでした。



これらのオプションはいずれも、いくつかの理由で満足のいくものではありませんでした。

• HTMLとSVGは多くの余分な荷物を運び、多くの場合、DOMを使用するため、2DキャンバスAPIよりもはるかに遅く動作します。 通常、ズームではなくスクロール用に最適化されており、ジオメトリはズームするたびに再カウントされることがよくあります。
• レンダリングがGPUを介してハードウェアアクセラレーションで渡されるという保証はなく、多くのことはまだCPUでレンダリングされます。
• HTMLおよびSVGでのマスキング、ぼかし、およびブレンドモードのサポートは、ブラウザごとに大きく異なり、高解像度ディスプレイでスムーズに表示されなかったり、出力が低すぎたりすることがよくあります。
• 2DキャンバスAPIはリアルタイムAPIであり、遅延APIではありません。そのため、すべてのジオメトリオブジェクトをフレームごとにGPUにリロードする必要があります。 この動作は必要なく無駄であり、ボトルネックになる可能性があります。
• テキストのレイアウトは、 異なるブラウザー間で同じではなく、異なるプラットフォームの同じブラウザーのバージョン間でも同じではありません。
• リストされているレンダリングAPIのいずれでもサポートされていないカーボングラデーションの描画などの機能を追加できるようにしたかったのです。

このいずれかを正常に機能させるのではなく、WebGLを使用してすべてをゼロから実装しました。 コンバーターは高度に最適化されたタイルベースのエンジンで、マスク、ぼかし、不均一なグラデーション、ブレンドモード、ネストされたレイヤーの透明度などをサポートしています。 すべての変換はGPUで行われ、完全にアンチエイリアスされます。



コードは、ブラウザ内のブラウザのように見えます。 独自のDOM、独自のリンカー、独自のテキストレイアウトエンジンがあり、ブラウザーでHTMLを表示するのと同じように、変換ツリーを追加することを考えています。

ブラウザ

Webプラットフォームの機能はまだネイティブプラットフォームに追いついていますが、残念ながら、あちこちにいくつかのギャップがあります。 大きなギャップを埋めるだけのリソースがない限り、理にかなっているときにできることを修正しようとしています。



Figmaの作業を開始する前に、カスタムの高DPIカーソルはWeb上で本当に壊れていました。 Chromeは 、 フォックスとWebkitを自分で修復する必要がありました。これらはすべて独自の方法で壊れていたからです。 これを操作する一般的な方法はまだありません（FoxのSVG、ChromeとWebkitの-webkit-image-set、およびIEの先史時代の.cur形式）が、少なくとも今ではすべてが機能します。



また、製品を改善するために、目立ったパフォーマンスとユーザビリティのバグを修正しました。 ウェブは時々フリークすることもありますが、ブラウザはブラックボックスではなく（ブラウザ自体を除く）、多くの場合、ウェブ上の迷惑なバグを修正するのに必要なのは、ブラウザコードの半日騒ぎ、うろついた一日だけですパッチについて、およびパッチを含むリリースを数か月待つ。



Figmaを改善するために、Webプラットフォームを改善できるものは他にもたくさんあります。

• 私たちの最大の苦痛は、キャラクターの輪郭とカーニングテーブルへのアクセスの欠如であり、現時点ではまったく入手できません 。 主な懸念の1つはセキュリティの問題ですが、 戦いはすでに失われています 。 フォントデータへのアクセスが、少なくともユーザーからの許可を要求するモード、および個人情報に敏感な他のAPIで開かれることを願っています。 Khromovites はこれを修正する方法を提案しましたが、現在取り組んでいますが、誰も地平線に迫っていません。
• クリップボード（.ai、.pdfなど）から人気のある形式でコンテンツを貼り付けるためのサポートを喜んで追加しますが、 Webではこれを許可していません 。 仕様の唯一の形式は、text / plainおよびtext / htmlです（Figmaは、HTMLコメントでエンコードされたバイナリデータでtext / htmlを使用します）。
• もう1つの問題は、OS Xのトラックパッドに対するピンチジェスチャのサポートの欠如です。Khromovtsyは、ピンチイベントがctrlを押したままマウスホイールイベントを送信し、ページでこれを処理できるpreventDefault（）を呼び出す、 あまり知られていないハックを追加しました。 それは素晴らしく、Figmaでの拡大とパンはネイティブな感じがします。 これをFoxに追加しようとしましたが、この試みはまだ行き詰っています。 Safariのピンチは増加のように機能し、ユーザーを混乱させ、これを無効にすることはできません 。

おわりに

パフォーマンスと品質は、当社の最も重要な品質の1つです。 彼らは通常の品質とは少し異なります、なぜなら まず第一に、彼らがいないときに彼らに注意を払いますが、彼らはすべてのトリックを行います。

この記事は、Figmaチームのブログの2015年の記事を翻訳したものです。 この記事は新しいものではありませんが、それでもかなり関連しています。 これは、Figmaチームのブログ翻訳サイクルの最初の記事です。 翻訳の著者はセルゲイ・ドゥルノフです。