17

私は、CSS3 トランジションを使用するスライドショー スクリプト、または利用できない場合の jQuery のアニメーションに取り組んできました。スライド アニメーションを適切に実行するカスタム関数を作成しました。すべてがうまく機能しているように見えましたが、テスト中に大きな問題が発生しました。

何らかの理由で、大きなスライドショーのトランジションの前後に jQuery CSS を適用するのに大きな遅延があります。たとえば、下のリンクのスライドショーは幅が約 9900 ピクセルです (コンテナーの幅で、ほとんどが隠されています)。コンテナーは、CSS3 トランジションとトランスフォーム プロパティを使用して、適切なスライドを表示するように操作されます。以下のペーストの 75 行目から 82 行目の間に CSS を適用すると、遅延が発生します。特に、'transition' CSS を適用すると問題が発生します。'transition' CSS を (JS で適用するのではなく) スタイルシートに追加すると、遅延がなくなります。ただし、これは実際には解決策ではありません。特定のプロパティで CSS3 トランジションを使用したいだけで、変化する可能性があるためです (スタイルシートで 'all' を使用すると、アニメーション化したくないが定期的に変更される CSS がトランジションされます)。

アニメーション機能: http: //pastebin.com/9wumQvrP

スライドショーのデモ: http://www.matthewruddy.com/demo/?p=2431

本当の問題は、スライドショー (場合によってはブラウザも) が完全に使えなくなる iOS にあります。エラーを特定することはできず、JS のデバッグに関する私の知識は本当に尽きてしまいました。少し遊んだ後、関数のこのセクションに関連していると確信しており、プラグイン内の CSS3 サポートを完全に無効にすると、問題が完全に解消されます。

私は完全に立ち往生しており、誰でもできる助けに本当に感謝しています。

- - 編集 - -

jQuery の .css 関数ではなく、ネイティブ Javascript を使用して CSS を適用しようとしました。同じ結果、より良いパフォーマンスはありません。また、これは Firefox ではまったく発生せず、Webkit ブラウザーでのみ問題になるようです。

解決策をお持ちの方は、ビールを数杯寄付していただければ幸いです。私は本当にこれを理解することはできません!

--- 二度目の編集 ---

OK、デバッグを行ったところ、ブラウザの再描画サイクルに非常に長い時間がかかっていることがスローダウンの原因であることがわかりました。これを処理するより良い方法はありますか? 要素を完全に配置することは、再描画を減らす方法として知られていますが、スライドショーはレスポンシブであるため、実際には機能していません。スライド画像またはスライド自体を絶対に配置すると、折りたたまれます。

--- 三回目の編集 ---

1日後、私はいくつかの進歩を遂げました。'transition: all 0s ease' を要素のスタイルシート CSS に追加すると、元の投稿で言及されているカスタム アニメーション機能を介してインライン CSS トランジション プロパティを追加することによって引き起こされる再描画がなくなりました。これにより、特にトランジション自体が終了したときにインライン CSS トランジション プロパティを削除すると、パフォーマンスが大幅に向上します。

いい物!ただし、トランジション後にインライン CSS トランスレートが削除され (ハードウェア アクセラレーション トランジション エフェクト自体を作成するために使用された)、左側の配置が適用されると、まだ速度が低下します。2 つが一緒に発生すると、速度が低下します。

それらを 2 つの別々のタスクに分割すると (翻訳が削除され、時間を指定せずに setTimeout に左の位置が追加されます)、再び再描画が取り除かれます = パフォーマンスが向上し、問題が解決したように見えます。ただし、CSS トランジション プロパティが十分に高速に無効化されず、変換の削除がアニメーション化される場合があります。ダメです。それを回避するために次にどこを見たらよいかわかりません。

4

6 に答える 6

1

まあ、私はそれを理解することができたと思います!ご存知のとおり、元の投稿リンクには、ローカルホスト環境で行った変更が反映されていません。

スライドコンテナを完全に配置することで、移行が行われた後(CSSプロパティを適用している間)の再描画速度で発生していた問題が修正されました。明らかに、それらをDOMから削除することでうまくいき、ペイントをより効率的に行うことができます。

これはサイズ変更機能に多くの作業を追加することを知っていたので、私はもともとこれをあまり試しませんでした。私はもともとJSでサイズを変更しないことを意図しており、汚い作業を行うにはパーセンテージに依存していました。コンテナを絶対に配置すると、スライドショービューポートが折りたたまれ、ネイティブのサイズ変更が役に立たなくなります。

しかし、とにかく他のブラウザでのサブピクセルレンダリングにすでに問題があったので、弾丸を噛んで固定ピクセル値に依存する時が来たと思います。次に、JSを使用して、ウィンドウのサイズ変更イベントを使用してサイズ変更を処理しました。すべてが良さそうですが、ポジショニングのためにスライドショーはまだ折りたたまれていました。高さの値の割り当てが正しく機能していなかったため、少し損失がありました。

ありがたいことに、スライドショービューポートの「パディングトップ」を動的に計算されたパーセンテージ値(このスクリプトの設定パネルで設定された目的のスライドショーの高さを目的の幅で割った値)に設定するというちょっとしたトリックに出くわしました。パディングトップのパーセンテージは要素の幅に相対的であるため、これはレスポンシブな高さを提供し、ビューポートを再度修正するという素晴らしい仕事をしました(もはや折りたたまれていないように見えます)。

アスペクト比を維持するレスポンシブエレメントにパディングトップを使用する方法についての情報を次に示します。ちょっとしたコツ: http: //f6design.com/projects/sensitive-aspect-ratio/

これですべてが順調に進み、iOSおよびWebkitブラウザーで問題なく動作しています。すべてが非常に高速で、正常に機能しています。4日後、ついに解明されました。サイズ変更のためにJSに頼らなければならないことに満足していませんが、ブラウザー間のパーセンテージの不一致のために、常にそうなると思います。小数点以下がたくさん=ダメ!

私を正しい方向に向けようとしたすべての人に感謝します。確かに私は考えさせられ、トランジションがうまく機能していることを確認するために再び使用できる多くのデバッグスキルを学びました。再度、感謝します!

于 2012-09-17T22:27:20.107 に答える
1

問題は、巨大な画像をロードしていることだと思います:)

それらはコンテナーに対して大きすぎるため、スケールダウンしますが、これはさらにリソースを集中的に使用します。

サイズを変更してみてください。

于 2012-09-14T14:24:38.037 に答える
1

コード TimeLine を Chrome Dev Tools で分析するのに時間を費やした後、実行できる最適化があると思います。

私の知る限り、アニメーションが要求されるたびに、16 枚の画像のすべてが完全に再描画されます。あなたの例には16個の画像があり、Chrome Dev Toolsはヒットするたびに16個の長い「ペイント」の実行を「次へ」と報告するので、これは私には明らかです。

私の謙虚な意見では、非表示にしたい画像と表示したい画像の 2 つの画像のみを変換することを考慮した解決策を考え出す必要があります。したがって、残りの画像を移動するのではなく、表示されている画像にすべて並べたままにすることを検討してください。

もう 1 つ、縮小した画像を使用すると、おそらくペイント サイクルがかなり長くなります。できる限り避けてください。

于 2012-09-17T09:28:46.640 に答える
1

まず、デバッグおめでとうございます!私は最近まったく同じことに取り組んでおり、iOS デバイスは同じページに配置された多数の画像をサポートしていないことがわかりました。それはクラッシュを引き起こし、私が見つけた唯一の解決策は、要素を非表示にするのではなく削除することでした. 欠点は、要素を削除して追加すると遅延が発生するため、遷移が完了したときに賢く行う必要があることです。最善の方法は、DOM に 3 つまたは 5 つの画像を保持し、残りを画像のサムネイルに置き換えて、元のサイズに合わせてサイズを変更することだと思いました。トランジションが完了したら、大きな画像を元の場所に戻します...これが少なくともiosの問題で少し役立つことを願っています...

于 2012-09-16T15:40:52.077 に答える
0

これは、マガジン カルーセル スタイルのページ デバイスを最初に設計したときのことです。

長い「トレイ」内に一連の画像がある場合、それらがビューポート内になくても RAM を消費します。リークや不快感が発生し始める前に、効果的に 5 枚程度を保持できます。

私が見つけたのは、それらを「隠す」ことです...しかし、それらが必要な物理的スペースを占めるようにしてください。

また、「前の」現在の画像と「次の」画像を表示し、トレイを移動して、これらの 3 つの位置に到達したときにそれらを「非表示にする」ことができることもわかりました。

私自身のシステムでは、e 画像を保持する「トレイ」をスキップし、-100% 幅、100% 幅、および現在の画像を 0 にしました。

大規模な背景画像を含む典型的なロングトレイカルーセルでは、あまり運がありませんでした...特にcss3アクセラレーションでは。

于 2013-03-08T04:12:57.893 に答える
0

これが役立つかどうかはわかりませんが、3D 変換を使用していることに気付きました - 特に 3 番目のパラメーターが 0 であり、問​​題を加速する可能性があるため、簡単な 2D 変換で十分だと思います。テストするiPhoneを持っていません...代わりに、これはcss3の前に使用したソリューションですが、左(?および上)を変更することにより、JavaScriptを使用して画像を含む要素を移動する必要があります。トランジション効果なし) そして、この方法でリフレッシュ レートを微調整することができます。これがスローダウンの原因と思われます... 誰にも気付かれずに 18 fps まで下げることができます。

于 2012-09-16T23:00:00.907 に答える