大きな写真の塗り直し

再描画はプロセッサによって行われ、ブラウザはこの特定の時間を費やします。 アニメーション化すると、この時間はパフォーマンスに悪影響を及ぼします。 100-200kBの高解像度の写真からリーフレットをアニメーション化する必要があるときに、この問題に遭遇しました。 さらに、多くのブラウザでは、問題はまったく悲惨なものに見えました。



この記事は、厳密であり、最終的な結論を出すふりをするものではありません。 しかし、私はコミュニティで発見を共有したかったです。 主な結論は次のとおりです。画像を使用した操作は、[canvas]を使用して実装する必要があります。[canvas]は、ビデオカードをロードし、グラフィックの単純なプレゼンテーションとして機能する通常の[img]タグを使用する必要はありません。



だから、今順番に。



次のタスクがあります。100%未満の縮尺の1つの画像を、同じ縮尺の別の画像に変更します。



「簡単なことはありません! imgタグのsrc属性を変更します。」そのため、Webkitベースのブラウザーでタイムラインを使用してこれがどのように行われるかを見ると、再描画イベントが生成され、大きな写真の回転にかなりの時間がかかることがわかります。



この場合、背景画像を変更してみましょう。 CSS3は、backgroung-sizeプロパティを使用してスケーリングできます。 少し速く。



独自のズームを使用する場合、状況もあまり改善しません。



キャンバスに絵を描いてみましょう-すべてが根本的に変わります! 再描画には0msかかります。



次のコードは、上記の内容を単純に示したものかもしれません(jqueryの使用は不当ですが、たとえばこれは重要ではありません):



<html> <head> <script src="https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script> </head> <body> <div style="display:none"> <img id="im1" src="img2.jpg"/> <img id="im2" src="img3.jpg"> </div> <div><span>IMG SRC</span> <div><img class="rotor" src="img2.jpg" style="border:1px solid #000;" alt="" width="400" height="200"/></div> </div> <div><span>BACKGROUND</span> <div class="rotor" style="border:1px solid #000; width: 400px; height: 200px; background: url(img2.jpg) no-repeat; background-size: 400px 200px;"> </div> </div> <div><span>CANVAS</span> <div> <canvas id="canvas" class="rotor" width="400" height="200" style="border:1px solid #000;"></canvas> </div> </div> <script> var ctx = document.getElementById('canvas').getContext('2d') var img = document.getElementById('im1') img.onload = function(){ ctx.drawImage(img,0,0,400,200) } $('.rotor').click( function(){ if( $(this).is('img') ) { $(this).attr('src', 'img3.jpg') } if( $(this).is('div') ) { $(this).css('backgroundImage','url(img3.jpg)') } if( $(this).is('canvas') ) { var img = document.getElementById('im2') ctx.drawImage(img,0,0,400,200) } $(this).css('borderColor','red') }) </script> </body> </html>
      
      







最終ページでは、3つの要素すべてでクリックイベントが発生すると、画像が回転します。 110kBの画像サイズで、図に示されている次の結果が得られました(これらは統計ではなく、特定の1つのケースの結果にすぎないことを強調したいと思います)。



画像



データは非常に多様であるため、同じブラウザ内でのみ比較でき、比較されるのは順序です。 私は彼らが客観的なランタイムを示すことを疑います。 Webkitブラウザーの場合、値は組み込みデバッガー(タイムラインタブ)から取得されます。 Firefox 7はdynaTraceを介して評価されました(残念ながら、IE9は同じツールで測定できませんでした)。



dynaTraceは一般にまったく矛盾した結果を生成しました。非同期モードでの実行時間を決定する期間フィールドは、3.98msの「クリーン」実行時間に対して424.54msの記録でした。



画像



また、Speed Tracer(Google)を使用した測定も驚きでした。値は250、84、84の形式で表示されます。一般的に、ある意味では、答えよりも質問の方が多いです。



画像



ただし、これらのサンプル計算を実際に確認しました。imgタグをcanvasに置き換えると、Chromeで1桁の高速化が実現し、Operaでのパフォーマンスが向上しました(通常、再描画速度の研究範囲外でした)。 Firefoxはより安定しました。 このすべてを、プロセッサからビデオカードに計算を転送することで説明しました。



[img]を他の目的に使用しないように説得できたことを願っています。 一方、ブラウザでの再描画の速度の測定については、多くの質問と困惑がありました。 コメントをお願いします。測定値付きのスクリーンショットを特別に提供しました。 方法論に対する批判は大歓迎です!



All Articles