Yandex.Browserの黒い長方形からChromium全体の加速まで

今日は、Yandex.Browserの1つの興味深いバグについてお話します。このバグを修正すると、Chromiumプロジェクト全体でレンダリングが大幅に加速されました。 そして、問題に対処するのに十分幸運だった私たちのチームのスペシャリストであるキリルdrBasic PleshivtsevとVadim Lof Petrovが私を助けてくれます。 私は彼らに床を与えます。











普通ではないバグ



私の名前はシリルです。ノボシビルスクのYandex.Browserの内部コンポーネントのグループで働いています。 それほど驚くべきことではない日、Yandex.Browserをテストした同僚は、Flash Playerでビデオを再生する問題を再現しました。 そして、ブラウザのこの部分（メディア、コーデック、それだけ）を担当するのは私たちのグループなので、タスクは私のところに行きました。 バグは、元のふりをしていないとしましょう。 [再生]ボタンをクリックすると、ビデオを正しく再生する代わりに黒い四角形が表示されました。 以前にこの症状に出会ったので、問題をかなり迅速に特定できると期待していました。 しかし、私は間違っていました。



文字通り、最初の数分で、黒い長方形が常に表示されるわけではなく、透明タイプのフラッシュ要素に対してのみ表示されることがわかりました。 半透明。 さて、デバッグ時にキャッチするものがすでにあります。 ブラウザのデバッグバージョンを収集して実行しますが、バグはありません。 そして、これは警鐘です。 デバッグバージョンとリリースバージョンの不一致は、常にとても楽しいものです。 そのため、リリースバージョンも収集することにしました。 収集、実行、バグなし。



私はそれについて考えました。 リリースビルドとサーバーがビルドするリリースの違いは何ですか？ ライブラリのレイアウトをすぐに思い出しました。 開発者は、shared_libraryモードでブラウザを構築します。 これにより、dllの数が増えますが、ビルド時間を大幅に節約できます。 ブラウザはstatic_libraryモードで配布されます。このモードでは、少数の大きなdllのみが収集されます。 static_libraryフラグを設定し、完全なアセンブリを実行します。 link.exeがすべてのRAMをゆっくり消費する様子を観察しますが、いや、16 GBのRAMですべての人に十分です。レイアウトはスワップファイルの形でドーピングすることなく終了します。 私はそれを始めています。 バグはありません。



私は真剣に考えました。 ビルドサーバーが公式フラグ付きのリリースYandex.Browserを収集することを思い出しました。これにより、動作が少し変更されます（後で詳しく説明します）。 このフラグで収集します。 震える手で、ブラウザを起動します。 あなたは今推測しましたか？ バグはありません。



それから私は真剣に不安になり、全力で考え始めました。 しばらくして、サーバーがVisual Studio 2013を使用してYandex.Browserを構築していることに気付きました。しかし、2015バージョンを使用しました。 2013年版で収集しています。 私はそれを始めています。 バグがあります！ 誰が私がそのエラーをとても喜んだと思っただろう。



問題全体がVSバージョンのみにあると考えた場合、あなたは間違っています。 このバグは、デバッグバージョンのブラウザーでは実際には再生されませんでした。 黒い長方形のエラーが表示されるためには、VS 2013を使用するだけでなく、公式のフラグを使用した静的レイアウトでブラウザーを構築する必要があることを実験的に確立することができました。 この奇妙な振る舞いの理由については少し後で学びます。



次の2日間も同様に興味深いものでした。 デバッグ中に、Flash Playerプラグイン自体がタスクを正しく実行していること、つまりビデオが再生されていることを理解できました。 ブラウザとの統合でも問題は発生しませんでした。 彼の作品の結果はレンダリングのために送信されましたが、何らかの理由で画面上でまったく異なるものを見ました。 これは、レンダリングを担当するブラウザの部分でバグを探す必要があることを意味します。 そして、ここでその言葉をヴァディムに渡します。



最適化する



既に理解したように、Vadimは現在連絡を取り合っています。 私はモスクワのYandex.Browserレンダリングエンジンの開発チームで働いています。 Yandex.BrowserまたはChromiumでのレンダリングの一般的な方法についてのいくつかの言葉。 ブラウザウィンドウに表示されるものはすべて、Photoshopのように、さまざまなレイヤー（Webページ、インターフェイス）を組み合わせた結果です。 Compositorコンポーネント（またはChromeのCompositor == CC）は、これらのレイヤーの操作を担当します。 しかし、すでにすべてのレイヤーを描画するために、SSは特別なオープンソースライブラリSkiaを呼び出します。



Cyrilと一緒になって、バグの痕跡がSkiaに伝わることに気付きました。 どこを正確に理解するかはまだ残っていました。 幸いなことに、私には貴重な手がかりがありました。 ほぼ最初に、シリルは彼女に言及しました。 問題は、透明性のあるフラッシュ要素の場合にのみ問題が発生することです。 このような要素を画面に描画するには、ブラウザでビデオ画像と背景を組み合わせる必要があります。 このため、Skiaにはブレンドを担当する特別な関数SrcATopがあります。 数分の検索で、Chromeで同様の問題を含むバグレポートがすでに見つかりました。



やったー 問題の原因を特定の機能に限定しました。 そして今、注目。 コードのこのセクションにはエラーは含まれていません。 まったくありません。 そして、ユーザーに送信される最終ビルドを除くすべてのビルドで完全に機能しました。 そしてVisual Studio 2013のみ。そしてその瞬間、Cyrilがこのバグを「面白い」と呼んだ理由に気付きました。



エラーの再現性に影響する他の違いを理解し始めました。 最後にのみ使用される公式の旗を思い出す時が来ました。 とりわけ、このフラグは最適化、またはむしろ/ LTCGパラメーターに影響します。 指定されると、コンパイラはプログラム全体の非常に深刻な最適化を実行します。 時間がかかるため、このようなアセンブリは収集されません。 しかし、最適化はどのようにエラーにつながるのでしょうか？ これを理解するには、小さなフラッシュバックが必要です。







2011年、Chromiumプロジェクトは非常に大きく複雑になったため、Visual Studio 2010リンカーは、リソース不足のため、かつてすべての最適化とリンクできませんでした 。 問題を回避するために、開発者はデフォルトですべてのサブプロジェクト（およびそれらの数千以上）を最適化することを、作業の速度（/ O2）ではなく、コードのサイズ（/ O1）によって決定しました。 そして、エリートで最も批判的な人、または所有者がこの状況で寝坊しなかった人だけのために、/ O2をオンにしました。 例えば、彼らはCCとSkiaのためにそれをしました。 2013年のみ、Skiaでのリファクタリング時に最適化が誤って失われました。 また、2年後にChromiumで別のリファクタリングが行われなかった場合、コードの一部が定型化されてヘッダーに転送された結果として、誰も気付かなかったでしょう。 そして、ここからすべてが始まりました。



そして、これが始まりました。 リリースブラウザーが公式のフラグでアセンブルされると、異なる最適化目標（速度、サイズ）を持つライブラリーが1つのdllになります。 これ自体は、何か悪い兆候ではありません。 たとえば、Visual Studio 2015では、これにより問題は発生しません。 スタジオは最適化に1時間をかけ、完全に機能するコードを生成します。 しかし、2013年バージョンに置き換えると、すべてが壊れます。 なんで？



Skiaでのブレンドを担当するSrcATop関数は、xmm0およびxmm1レジスタを介して2つのパラメーターを取ります。 そして、ほとんどの場合、正しく機能します。 しかし、デバッグ中になんとか見つけたので、VS 2013と難しい最適化をここに追加する価値があり、関数は、応答で最初のレジスタの内容を返し始める程度に縮退します。 したがって、ビデオの代わりに一定の黒い背景が表示されました。 犯人はVS 2013の誤ったコード生成でした。



Webサーフィンの高速化



必要に応じて、SrcATopを少しねじることにより、バグをローカルで「修正」できます。 しかし、Skiaのようにレンダリングに重要なこのようなコンポーネントには速度の最適化が欠けていると思われました。 そこで、Skiaの速度最適化を設定する新しいビルドを作成しました。 もちろん、バグはなくなりました。 タスクを閉じてお茶を飲むことができるように思えますが、違います。 私は別のことをしなければなりませんでした。



Yandex.Browserチームは、数年間Chromiumの開発に参加しています。 そして、これはバグの修正だけではありません。 かつて、同僚はHTTP / 2のサーバープッシュの実装と、Windowsのプロジェクトのビルドシステムを支援していました。 したがって、今回は問題の解決策を提案し、検討のために既成のコミットを送信しました。これは短い議論の後に採用されました。



私と同じように、Chromiumの開発者はブラウザーのパフォーマンスの変化を見ることに興味がありました。 したがって、彼らはあらゆる範囲のパフォーマンステストを実施しました。 Windowsのほとんどすべての指標が成長しています。 低レベルのテストの一部では、2〜3倍の改善が示されました。 主要なサイト（つまり、毎日のWebサーフィン）の統合FPSテストは6.5％増加しました。 入力に対する応答性が20〜30％向上しました。 Chromiumプロジェクトでは、同様のレベルの最適化は毎日行われません。











VS 2010が長い間使用されていないことを考えると、プロジェクト全体で速度の最適化を有効にすることをお勧めします。 さらに、通常のリリースビルド（公式フラグなし）は常に速度が完全に最適化されており、テストに問題はありませんでした。 しかし、これはまったく異なる話です。



PSこの特定の問題は、2つのオフィスにのみ影響しました。 実際、Yandex.Browserはモスクワとノボシビルスクだけでなく開発されています。 サンクトペテルブルク、エカテリンブルク、ニジニノヴゴロド、ミンスク、キエフにもチームがあります。 そして、あなたがそれらに参加することに興味があるなら、 yandex.ru/jobsを見てください 。