Canvasで降る雪のアニメーションは、DOMのアニメーションよりも数倍効果的です

。 DOM要素のネイティブJSと比較して、Canvasでのアニメーションアルゴリズムの実装は通常、何倍も生産的です。 これはよく知られた事実ですが（後で説明する少数のパーティクルの機能を使用）、従来の「NG」を妨げるもののすべてを実装する方法を見つけることができますが、合理的なユーザー「雪が降る」に駆動されます。 負荷を軽くするために、近年では、最小限の雪片（5〜15）で、ほとんど目立たないように、サイト上で雪を「発射」するのが良いと考えられています。 効果があり、プロセッサにほとんど負荷がかかりません。



したがって、冬がNGまで数日になるまで 、キャンバスに最高のアルゴリズムとDOMの類似物を実装するためのハッカソンを手配することを提案します。主に古代のネイティブアルゴリズムをベースとして、最大でjQueryプラグインでラップして接続しやすくします。 これらのアルゴリズムのほとんどは、プロセッサの負荷を分散していないか、効率が悪いため、雪片の数が少ない場合でも、プロセッサの負荷は100％です。 以下はレビュー記事の例です 。10を超える実装が考慮されていますが、すべてが自然界にあるわけではありません。 さらに、アルゴリズムの開発とその実装を効率よく行うための基盤を得るために、いくつかのお気に入りを検討します（別の5〜6のオプションを取得します）。 これに基づいて、リビジョンを作成できます。 Githubには12のデモ（以下にリンクを繰り返します）といくつかのアルゴリズムがあります。



いつものように、Habréの記事の寿命は1.5日を超えないため、有効な在庫を数えることはできません。 しかし、新年の後、さまざまな奇跡が起こります。訪問者の流れが落ち、ランダムな狂人が5日間、1つの記事を忘れないチャンスを得ます。 彼らは彼らに賭けた。



匿名のサンタクロースのクラブなどの長いプロセスに結び付けられており、「雪が降る」ためのオプションを議論し、開発するためのバインディングをいつでも取得できると同時に、休日に密接に結び付けられていない方が良いです。 結果は現在ここにあります： geekadm.ru / # / 2015 、そしてもちろん46.101.141.171/snow.html?v=4のような中間実験があります-HabraAdmの雪には追加の効果があります。



予備的な「ハッカソン」は、1対の参加者と（または）クラブの訪問者（1） 、 （2）によってアレンジされました。 その結果、Canvasを使用したエンジンで最大10個のオプションが判明しました。 それらの数ははるかに多くなる可能性がありますが、すべてに自由時間が必要なので、アクションはオープンなものに変わりました。 たとえば、Peter Gehrigによる雪片の落下モデルを2003年に既に作成されたエンジンに「ねじ込む」ことができます。 2005-2006年の改訂では、20-30枚の雪片がプロセッサにわずかに負荷をかける（10-20％、電源とビデオカードに依存します。以下、JSはシングルスレッドであるため、 1つのプロセッサコアの読み込みについて説明します ）古いフォーラムによると、Opera 9やIE6などの古いブラウザーでも同様でしたが、やや劣っていました。 同じアルゴリズムを使用するCanvasでは、5倍以上のオブジェクトを実行できます。









デモ

歴史を見て、そのコースを見てみましょう

2002年から2005年頃まで、最初から始めましょう。 Javascriptは、落下する雪片をアニメーション化する能力を示しました。 確かに、それは判明しました。当然のことですが、スクリプト上のアニメーションは非生産的であるか、プロセッサに大きな負荷をかけています。 そのため、当時はリソースを大幅に節約するか、ブラウザストリームで最大100％までプロセッサをロードする必要があり（1コアで）、他のタブ（Opera 9などのブラウザ）とウィンドウを遅くしました。そして、これはそのようなページへの訪問者のひどく隠されたdigりを引き起こしました。



8年後、この問題の解決策がブラウザーレベルで見つかりました。 Chromeから始まる主要なブラウザは、非表示のタブでスクリプトの実行を一時停止し始めました。 これは、他のウィンドウやプログラムの表示を妨げないようにしました（ただし、別のウィンドウに切り替えても一時停止せず、ウィンドウが画面に描画されていないか、部分的に表示されている場合のみ負荷を軽減します）。 ただし、モバイル時代に関連して、アニメーションを読み込んでページを開くことはまだ積極的に認識されていません。



しかし、長年にわたって、より高度なアニメーションメカニズムであるCanvasが登場しました。 別の革新的なメカニズム-CSSのアニメーション-は負荷を節約するのに役立ちません。また、Javascript + DOMのアニメーションとまったく同じようにプロセッサのエネルギーを消費します。 つまり、最適なソリューションを探す場合は、Canvasで行う必要があります。



例でわかるように、Canvasでは、平均的なデスクトップコンピューターまたはラップトップで、30〜40％の負荷で100個の雪片を起動できます。 これは、最適化されたJS + DOMアルゴリズムが実行できるよりも約5倍効率的です。



歴史へのオマージュとして、最適化とCanvasへの変換を待っている「古典的な」アルゴリズムを検討します。



「snowfall js」、「snow flakes js」などの単語をGithubで検索すると、多くのアルゴリズムを簡単に見つけることができます。 これらは、 上記のデモリンク （または拡張コピー ）で12のスクリプトの適切な選択を補完します 。

アルゴリズムの概要と例

（例を含むページを表示するときは、プロセッサコアの100％の読み込みに備えてください。記事にリンクを表示するときは、読み込みレベルが警告されます。）



多くのアルゴリズムは、効率が悪いことに加えて、雪片の実際の動作と動作が似ていません。 おそらく、多くの人は、正弦波上の雪片の動きの現実の印象的な不一致を覚えています。 一度（またはより新しい ） 見られると、否定的な例として長い間記憶されています。 したがって、アルゴリズムのタスクは効果的であるだけでなく、現実を反映することでもあります。 （効率の観点から、調和関数の計算も失われるはずです。）



以前にレビューしたアルゴリズムのうち、2つは現実に最も近いと考えることができます-ランダムな動き（座標ではなく速度を変える必要があります）と前述のPeter Gehrigアルゴリズム（2003）では、動きは4つの変数によって制御され、そのうちの1つは調和的に変化し、 「ねじれ」の周期的な影響。 ただし、この機会に、新しい実装を議論して貯金箱に追加できます。



見つかったP. Gehrigアルゴリズムの実装から、例のあるページが見つかりました： www.softtime.ru/javascript/snow-falling.html 。 何が危機にatしているのかは明らかです。 少数の雪片（15-20）がプロセッサーをあまりロードしません（弱いノートパソコンでは10-20％）。ChromeおよびFirefoxで動作しますが、Opera 9、IE5および6、および初期のFirefoxの一部はサポートリストに記載されています。 もちろん、彼らはCanvasを知りませんでした。



私たちが見たものをテーブルに持って行きましょう。

*）粒子の数。

*）アニメーションのタイプ。

*）実験用のサンドボックスの存在。

*）CPU負荷（MacBook、Firefox 43）（Chromeは通常10％効率的です）;

*）機能に関するコメント。



（実際のプロセッサロードデータは、さまざまなコンピュータ、さまざまなグラフィックカードを搭載したコンピュータ、および広範囲にわたるモバイルデバイスに対して示されたものとは異なります。これらは、グラフィックスが統合された中電力ラップトップの向きを示しています。）



Canvasを使用してスクリプトを簡単に見てみましょう。

純粋ではないjs	デモ：400x400、 雪が降る雪だるま
デモごとのパーティクル： 100
タイプ：キャンバス
サンドボックス- はい
負荷： 70％
コード行： 106 + ProcessingJS（800K）
これは、Rapierのような言語を作成する800Kの非圧縮コードのProcessingJS環境で描画されます。 雪だるまは同じコードで描かれています。 例は特別なものです。 （複雑な方法で単純な問題を解決するために）シェルで何でもできることを示しています。この場合でも、Canvasは壊滅的にDOMソリューションに負けていません。
記事（en） 、2012	コード： Github	デモ： 全画面
デモごとのパーティクル： 500
タイプ：キャンバス
サンドボックス？ いや
負荷： 100％
コード行：* .html + ThreeCanvasJSの50 + 100（72K）
ThreeCanvas.jsライブラリからの72K圧縮アンパックコード。 マウスの動きが回転する3Dシーン。 ここでは、スムーズな動きのために低ビットレートが設定されているため、すべてが美しいですが、バックグラウンドアクションとしてはあまり適切ではありません。
年：2010	コード： JS	デモと説明： 全画面
デモあたりのパーティクル： 60 、画像の平面内でスピン
タイプ：キャンバス
サンドボックス？ いや
負荷： 100％
コード行： 160
非常に頻繁なアニメーションでは、Canvasの利点を理解できません。 描かれた雪片はその軸を中心に回転しており、さまようことのあるゆっくりとした落下です。 しかし、それらのいくつかは正弦波に沿って「歩き」ます。1つの平面のねじれはまったくリアリズムを与えません。反対に、効果の知覚を拒否し、むしろ重要な効果を作成します。 コード-それどころか、その力とコンパクトさを示しています。 要するに、優れた努力は、消費者に対する効果とはわずかに異なる効果を達成することを目的としています-DOM上のエネルギー消費エンジンよりも優れていません。
CanvasなしでDOM（レイヤー）で動作するスクリプトの例を見てみましょう。
年：2009	デモ： jSnow-jQuery Snow Effect 、フルスクリーン		コード： JS （非圧縮のレガシー）
デモごとのパーティクル： 25
タイプ：DOM
サンドボックス？ いや
負荷： 70％
コード行： 160 + jQuery
Fiddleサンドボックスのオプション（どこでもシンボリックスノーフレークが使用されます）： jQuery 2に適応した、サンドボックス内のパックされた（難読化された） オリジナルコード 。 パックされていないが、jQuery 2に適応したサンドボックス内のmod 1のmod 1コードの動きが悪い（小さな正弦波）。 サンドボックス内のこのスクリプトの名前、スタイル、 最も類似した動作コード（フィドル）のリファクタリングにより復元されました。 停止ボタンで停止/開始します。 圧縮形式で-1.5K。 ブロックまたはウィンドウ全体で複数のオブジェクトを実行する機能に拡張されました。 コレクションを実行します。 圧縮形式-1.8 K、オリジナルよりも小さく、異なるmodの場合は2.2〜2.4です。
このスクリプトには、粒子の動きの特徴的な手書き文字があります（側面に強く）。 よく見ると、これらは非常に大きな正弦波であり、窓の中央にある大きな渦巻きのように見えます。 彼は資源の浪費に非常に拘束されています。 ソースコードバージョン1.2-パッカーによって紛失または常に難読化された。 アンパックされたバージョン1.1.mod2（他の作成者によって変更された）-Codepenサンドボックスにありますが、キャンセルされた$ .browserを参照するため、新しいjQueryでは機​​能しません。 そして、彼らは開梱の兆候を示しています。 正弦波が見落とす時間がないときに、低いヘッダー（ 例 ）で見栄えがします。 数十の例のうち、2つ（実行とコード）を詳しく見ると、この例もその1つです。 そのため、サンドボックスでjSnowバージョンを実行して徹底的に取り上げます。

興味深いことに、作成者のパッケージバージョン1.1または1.2ははるかに高速です（同じ外部設定でプロセッサにロードされるのは40％で、 1.1.mod2は55％です）。 （マルチウィンドウモードではフィドルも高速に動作しません。）おそらく、不必要なチェックはスノーフレークレンダリングサイクルに影響を与えます（「機能」がmodに追加されました）。 コード自体はあまり最適化されていません-ルールで設定できるインラインスタイルを記述します。



その後、より興味深いものになりました-テストされた設定でコード内に多数のバグが見つかりました（これは、全員が見つかったという意味ではありません）。 コードにいくつかの変更を加える必要があります（jQ 2+との非互換性を削除し、スノーフレークの初期位置を計算し、ウィンドウの左端を超えないようにします-ポピーでは、スクロールバーの「点滅」につながり、下の境界線でも同じことを行うと便利です）、より改良された最新バージョンを使用してください。



Mods-versions（2009-2010）はいくつかの緊急の「機能」を追加しました-雪片のスムーズな消失の設定（fadeAway：1）および雪片のフィールドを移動せずにスクロールする機能（followScroll：1）。 開発者が呼んだように、名前は元のままです。



古いコードをデバッグする目的は、アルゴリズムをCanvasに転送し、速度を比較することです。 （勝つための障害-十分な名誉ではありません。）設定では、他の人を批判したのと同じ間違いを繰り返します。 開発者にとっては、2Dで降るマルチカラーの雪が発生しないことは重要ではありません。主なことは、カラー化する技術的な可能性があることです。 それでも、雪片が飛ぶのではなく、現実には塊があります。 しかし、地球の人口の3/4がこれを知らないため、成功が待っています...雪片のセットでは、雪片に似たほとんどのUnicode文字が使用されました。



そのため、機能を失い、ストップスタートボタンを追加することなく、最高のMODよりも20行短く（90行）、パック形式で30％少ない（1.5K）読みやすいコードが判明しました。 この中間バージョンはコンパクトですが、以前と同様にウィンドウで機能し、パラメーターで高さ（高さ：数値）を絶対に設定できます。 特にプラグインはコンテキストコレクションをまったく使用しないため、これはあまり便利ではありません。したがって、$（）の奇妙な外観で問題ありません。JSnow（...）、つまり コンテキストなし。 簡単にわかりましたが、 ここではデモへのリンクに限定します 。



そして、タスクを複雑にします-jQueryコンテキストコレクションの使用を開始します。 コンテキストがない場合、この動作を保持します-ウィンドウと$（ 'body'）のコンテキストのように、ウィンドウでの作業を選択し、コンテナーブロックでの作業を追加します（たとえば、$（ '。ContSnow'）で実行します。 。））。 コンテナを準備する必要があります。絶対位置の挿入されたブロックが心地よいように、位置：相対が必要です。 ウィンドウ全体で異なる動作をするブロックはウィンドウをカバーするため、そのようなブロックがある場合はすべてのページコンテンツを上げる必要があります。 （それ以外の場合は以前と同様に可能ですが、なぜ複雑なのでしょうか？むしろ、最初のスクリプトまたは2番目のスクリプトのいずれかを使用します。）次のような結果になります。



デモ （レポジトリ内のコード） これはDOMです。負荷はストリームあたり30％（15％-合計）で、ビットレートは12です。

写真が大きく透明であるという事実にある程度影響を受けています。



実際、jQueryがコレクションを提供できるのに、なぜ1つのコンテナーだけで動作するのですか？ 70-120個のパーティクルに対して30-50％の負荷がかかることが判明しました。 ストップスタートは、ボタンに分割するか、共有することもできます。



書かれたものを適用しようとすると、すぐにコレクションでスクリプトを実行することの非実用性に目がいきます。 実行-はい、数十個のスクリプトのインスタンスでさえ、雪片のそれぞれに配布できます。 ただし、同じパラメーターがコレクションのすべてのブロックに報告されますが、これは実用的ではありません。 より多くの場合、別のタスクを実行する必要があります-いくつかのウィンドウ（仮想、ディーバ）を起動しますが、異なるパラメーターを使用するため、1つの要素にそれらを伝える必要があります。 ほとんどの場合、多くの要素、非常に多くの.jSnow起動が必要であることが判明します。



CSSルールを記述することと類似しています。 ルールは、プラグインを実行するときに行うパラメーターの宣言と同じです。プラグインのセレクターも配置されます。 しかし、現在、メカニズムがルールの記述を徐々に蓄積する方法はありません（一方のフォントサイズと他方のフォントサイズに似ています）。 同じ要素でプラグインを2回起動すると、プラグインの別のインスタンス（クロージャーとシャットダウン機能を備えた長時間実行機能）が追加され、既に実行中のプラグインにはプロパティが追加されません。 この場合、JSON設定ではなく、セレクター（クラスを持つ文字列のみ）をリストする方が便利です。 しかし、設定を作成するこのような方法が必要であり、機能する単一のプラグインを思い出しません。 デモの最も高度なバージョンでは、プラグインができるように4つの領域で起動を作成します。





demo 、 （レポの猫） 、75個のパーティクルと12 FPSで50％を読み込みます。



プラグインの改善により約300バイトの圧縮コードが追加されましたが、今ではより多くの理由でプラグインと呼ぶことができます。 確かに、1つのメソッドはありません。

DOMを操作するためのその他のスクリプト

そのような注意は、最も高度なスクリプトではなく、1つのスクリプトに向けられています。先を見ると、それはCanvasスクリプトの少しの競争相手であることがわかります。 効果的に書かれていないものは競合他社にはなりません。したがって、コードに余分なものを許可することはできないため、比較対象があります。



たとえば、 Snowstormという非常に人気のあるDOMスクリプトがあり、20Kの圧縮コード、非常に多数の設定、モバイルデバイスでの無効化などがあります。小さなスクリプトについて学ぶべきことがあります。 しかし、余計なものとそれが損失につながるかどうかを研究することは、難しい作業です。 簡単に書いて設定を拡張します。 それぞれの重要性は、テストと実践を通じて明らかにされます。



すぐに別の小さなスクリプトを見ていきましょう。これは、適切に設計されたデモやサンドボックスには見られませんでしたが、興味深い動作があります（上記のP. Gehrigによる）。 サンドボックスに置くのに大きな困難はありません。改善の必要はありません。jQueryはそれを使用しませんが、現代のdoctypeに慣れるには時間がかかりました。 また、システムフォントの特殊なUnicode文字では以前は問題がありましたが、今では改善されているため、落下する文字は落下するテキスト（強調表示された）雪片に置き換えられます。

年：2005年、 設定 、 コード 、 jsFiddleで 雪が 降る
デモごとのパーティクル： 25
タイプ： DOM
サンドボックス？ はい
負荷： 10％ （8 FPSによる）
コード行： 90
元のスクリプト設定でのこのような小さなシステム負荷は、FPSセットが低いために発生します。 もちろん、これは頻繁なスライドショーとしての動きで顕著です。 これは古いブラウザに必要であり、古いスクリプトのコメントで警告されています。 30 FPSでは、負荷は35％で、同じ設定の以前のスクリプトとほぼ同じです。 このスクリプトには、ブラウン運動を追加し、画面の「遠方から」の落下、増加および「融解」（透明度の増加）付近または下への変更が加えられています。
年：2006年、 設定で「遠くから」落ちてくる雪 、 jsFiddle
デモごとのパーティクル： 25	（フルスクリーンで見る）
タイプ： DOM
サンドボックス？ はい
jsFiddleにダウンロード： 60％ （16 FPS）
コードの行： 100
ここでは、サイズ設定は非常に「気まぐれ」です-成長率のわずかな変更で、巨大な雪片を取得するか、成長しないことができます。したがって、他の行動シナリオを選択する必要があり、効果は最終的にウィンドウのサイズと行動に依存します（自動調整ではありません）。 負荷の顕著な増加は、大きな透明な文字（画像）のレンダリングに関連しています。 （ソースコードは厳密に記述されているため、間引き後の実際のコード量は2倍になります。）

Githubですべてのコードオプションをsnowで書きましょう。 デモページを作成しなかった前任者の欠陥を考慮に入れるため、コードを見る人ははるかに少なくなります。 Githubを使用すると、gh-pagesブランチで作業する場合にデモを非常に簡単に実行できます。 これで、すべてのバージョン変更が変更履歴に簡単に記録され、違いが見られます。 Github： github.com/spmbt/snowfalls

CSSアニメーションはどうですか？

さらに、効果的なアルゴリズムと素晴らしい結果を求めて、他の人が書いた例を見ていきます。



1. DOMスノーフレークの回転を伴うCSS3の負荷の高いアニメーションの例（ほぼ唯一のCSSアニメーション ） -www.jqueryscript.net/animation/jQuery-Plugin-For-Snowfall-Effect-with-Rotating-Snowflakes.html （このサイトには、スクリプトごとの説明、コード、デモがありますが、サンドボックスはありません。）



2. CSS（Codepen）の3つの画像レイヤーのアニメーション。



システムにあまり負荷をかけないスクリプトを見つけるために、キャンバス上でより多くのアニメーションを見るようにします。



マウスの動きによってアクティブにされるCanvasのアニメーションの例では、許容できる雪片の数は、画面上で約200-300からの連続生成ではなく、約50-100であることがわかります-www.jqueryscript.net/animation/Yet-Another-Falling- Snow-Animation-with-jQuery-Canvas-GlauserChristmas.html



ライブラリのないCanvasの別のアニメーション、中国語のデモとコメント： www.jqueryscript.net/animation/Nice-Snow-Falling-Effect-with-jQuery-Canvas-Nice-Snowing.html



何らかの理由で、Canvasを含むこれらすべてのアニメーションは、プロセッサ（より正確には、シングルスレッドJSがロードできる1つのコア）をロードするように設定されています。 これは、スクリプトのデモでは正常と見なされるようです。 （おそらく、これは個別のグラフィックスカードで当てはまります。）

どういうわけかそれはすべて奇妙です

snowを使用したスクリプトの中で、CPUセーバーはほとんどありませんが、DOMとCanvasの両方で使用できます。 100個ではなく、数千個の雪片でも同じ全負荷効果が得られることを示しています。200-400個の場合、通常のカーネル負荷を10-20％考慮することをお勧めします。

効果的なキャンバスの選択

ただし、クリーンなCanvasには経済的なスクリプトが1つありました。 ほぼ彼のスタイルで例を行います。

年：2015	デモ： HTML5 CanvasとJavascriptを使用した雪効果 、フルスクリーン		jsFiddleにコピーする
デモごとのパーティクル： 25
タイプ： キャンバス
サンドボックス- はい
負荷： 45％
コード行： 90
この例は、上記の例のように、これ以上何もしないすべてのコードを制御する場合、成功は近いことを示しています。 200個のパーティクル（Chrome内）でも負荷は45％（2つまたは3つのプロセス-Chromeと2つのChromeヘルパーを監視する必要があります）、2000年では60％です。Firefoxの場合-ほぼ同じですが、10％遅い（良い条件下）よりランダムな抑制因子。

しかし、キャンバスは軽負荷では問題があります。 多くの場合、2つのパーティクルでの負荷は40〜60％で、25の場合と同じであり、実行されていないsetInterval（）の場合は0です。 ドラフトを作成するとプロセッサーがロードされ（30 FPS-30の割合）、ドラフトの量はそれほど重要ではありません。 明らかに、ビデオカードの品質が悪いと、結果は悪化し、どこかで改善が見られなくなります。Canvasがある場合は常に速度が低下し始め、FPSを下げることによってのみ修正を行うことができます。



より詳細には、結果は次のとおりです。 結果への影響が少ないjsFiddle を使用し 、停止ボタンを追加してサンプルをコピーします。 プロセッサの費用が落ち着くまで（マウスを動かさずに、何もせずに）別の数の雪片を開始し、1分ほど待ちます。 アクティビティモニター（Intel HD Graphics 5000ビデオを搭載したMacBook）で結果を確認します。 たとえば、4コアプロセッサでWindowsを見ると、25％を超える負荷はありません。 記事でここで言及されている100％は、シングルコアの読み込みに関連しています 。 25％に4を掛ける必要があります。ブラウザは異なる方法で並列化する方法を知らないだけですが、ラップトップのこの負荷は非常に敏感であり、おおよそビデオを見るときのようにエネルギー消費につながります。



未完成のレンダリング-10％の負荷（バックグラウンド）。

0粒子-30％;

2パート-35％;

25個の粒子-40％;

200個の粒子-50％;

1000-55％;

2000-65％。

この場合、読み取りは常に繰り返されるわけではなく、他の実行中のプログラムとメモリ使用量に依存します。



これが、Canvasの出現により、誰もがすぐにプログラミングを急ぐことがなかった理由の鍵です。 プロセッサ、実装の最初の可能な不完全性、およびブラウザでの不完全なサポートにより、許容されるビットレートを実現できなかったため、動きの質が良好な場合、パーティクルの数ではなくビットレートに依存し、同時に理想的には20％に収まる「パフォーマンスの資格」を渡すことができました。 レイヤー上のアニメーションを使用すると、少なくとも5つのパーティクルを実行し、この資格に合格できます。 パフォーマンスが向上し、Canvasを使用しないIE8では約0.5％になりました 。

カスタムキャンバスアルゴリズム

canvasで経済的なアルゴリズムの独自のバリアントを作成しましょう。 最初に、平面をトーラスに閉じ、雪片を各粒子の速度に適用される小さなランダムウォークで風下に移動させます。 突風の印象はありませんが、それは非常に自然に判明します。 2番目の効果は視差です。これは、小さな粒子がよりゆっくりと落下する場合で、シーンの立体感を生み出します。



このような設定では、最初のパンケーキが行きました。

年：2015	: , ,
: 100
: Canvas
—
: 35%
: 50
, , , , . «» , . *.999 «». , . , . — . , , , ( , ).
	2 : ,
: 1000
: Canvas
—
: 40-50% (30 FPS)
: 50
, : , . «» . , . , . . , , . . , ( , 30% , 120 ).

Kafeman

並行して、カフェマンは雪やその他の休日の効果で台本を作りました。

最初のアイデアは、ADMクラブの訪問者に効果のあるウェルカムページを作成することです。すべてがより深刻になる可能性がありますが、歴史は仮定法の気分を許容しません。加えて、純粋に実際の降雪（見に訪れたアイデアを装飾1、2、3）と密接にそれらの不快なちらつきの雪粒子をシミュレートします。完璧はまだ達成されていませんが、方向にはあらゆる理由があります。そうでなければ、顔に彫られた気を散らす雪は記憶されません。ここでは、形のないフレークとそのぼやけたちらつきのレンダリングを試す必要があります。



そして、何らかの方法で積雪を成長させる必要があります：jsfiddle.net/162e4jte/3ですが、宇宙飛行士が惑星全体を飲み込むほどではありません。最初に、彼は結核として解体し、溶けました：jsfiddle.net/162e4jte/1。この動作は、他の著者のスクリプトで発見されました。



まあ、将来的には、エンジンジェネレーターを1つに結合するというアイデアも実行に値します。結果によると、サードパーティの著者のスクリプトの塊に加えて、3〜4個のパーティクルモーションアルゴリズムと2つの実装方法があり、それらの共通部分は提出されたサンドボックスとリポジトリでかなり良好です。



いくつかの統計。地球温暖化により、スキーと同様にJavascriptと連動した雪への関心が低下しており、CanvasとJavascript-成長しています。これで、どの組み合わせで安定した関心が確保されるかがわかります。

おわりに

雪の効果に対して実際に実行可能な2つのプログラミング方法（DOMレイヤーとCanvas）には、独自のアプリケーションニッチがあります。最大約50個のパーティクルで、DOMが勝ちますが、すべてのモードではなく、プロセッサーの負荷が小さいタスクが必要です。高ビットレートはバーを下げます。50を超える（ただし、自信を持って-200を超える）-低いビットレートが望ましい-Canvasが勝ちます。ただし、プロセッサリソースの30％からダウンロードを増やす必要があります。境界と基準は非常に不安定であり、ハードウェア、ブラウザ、ブラウザでのエンジン実装の成功に依存します。モバイルユーザーは、5個以上のパーティクルに対して「ノー」と断言します。大きなビデオカードを使用する静止画は、DOMの200個のパーティクルとCanvasの5000個の問題を真understandに理解しません。



典型的な商用アプリケーションのアルゴリズムから余計なもの（休日のエリアでのユーザーの注意）はすべて削除し、異なるデバイスでアルゴリズムをテストし、ユーザーカバレッジのニッチについて決定する必要があります。 Canvasでより多くの勝利を収めた低ビットイルミネーションや、短期的な花火があるかもしれません。どのボタンでアニメーションをオフにし、ユーザーの設定で「アクションがうまくいった」ことを覚えておいても問題ありません。雪はYandexブラウザほど金銭的ではないので、このボタンを意識的に「壊す」理由はありません。数年のうちに、キャンバスの状況が改善され、少数のパーティクルと増加したビットレートの領域をゆっくり選択することを期待できます。



雪の台本の表現の可能性は基本的にこの段階で使い果たされます（このグループでは近年、質的に新しいものは登場していません）。十分に完成したスクリプトには、必要に応じて認識される多くのプロパティがあり、一部のパフォーマンス上実行不可能なプロパティ（3D形式での雪片の回転）は実行されませんが、これは誰にも迷惑をかけません。ただし、キャンバスでの生産的なレンダリングにより、このようなスクリプトが表示されることが予想されます（30％の負荷で）。



コーディングの視点-設定によってDOMまたはCanvasのオブジェクトを提供するコンストラクターを作成できます。デザイナーは異なる著者を書くことができます。 ：このアプローチでは、プロジェクトがHabraADMe（Githab）に編成されているgithub.com/clubadm/snowmachine。このリポジトリからjsFiddleを介して現在のコードを実行します。