問題タブ [reflow]

概要

フォーム入力のテキストをクリアすると、Chrome で長い遅延 (数秒) が発生します。これにより、計算されたスタイルのリフローまたは再計算が発生しているようですが、よくわかりません。Chrome の Profiler と Timeline は参考になりませんでした。

遅延の原因は何ですか? どうすればそれを取り除くことができますか? これは私のコードのエラーですか、それとも Chrome のバグですか?

例

http://jsfiddle.net/jmilloy/dHFsQ/

遅延を発生させるには、入力に入力してからテキストを削除します。最後の文字を削除するか、すべてを選択してから削除すると、遅延が発生します。

遅延をなくすには、 、、またはrow4の代わりに使用します。これで、遅延を引き起こすことなく入力をクリアできます。row1row2row3

ノート

• 遅延はn、行数によって異なります。

• Chrome では発生しますが、Firefox では発生しません。

• Linux (Ubuntu/Mint 11) と Windows 7 では発生しますが、OSX では発生しません。誰でも確認できますか？

遅延動作を示すjsfiddleを取得したら、この質問を完全に書き直し、より単純な例で再度書き直しました。

要素の高さの計算中に奇妙な問題が発生しています。最初は高さ 0 で、元の高さにアニメートします。setTimeout を削除すると、高さは常に 0 になります (プレーンな JavaScript を使用している場合でも)。

これを回避する方法はありますか？

element.offsetWidth要素の寸法の再計算 (またはリフロー?)を読み取るとどこにでも書かれています。

ただし、この効果を目に見えるようにするのに苦労しています。

クロムでは、次の 3 つの簡単な手順で表示できるようになると思います。

1. Chrome 開発ツールを開く
2. 要素タブに移動し、再計算/リフローを発生させたい要素を選択します
3. タイムラインタブに移動し、録音を開始します
4. コンソールに移動して入力します$0.offsetWidth

ここで、タイムライン タブに移動すると、リフローが描かれていると思います。しかし、何も見えません。だから私は何か間違っていたに違いない。

ブレークポイントに次のルールを使用して、エッジ リフローを使用してレスポンシブ サイトを設計しています。

<480px, <768, 1024>

それぞれの幅のブレークポイントごとに異なる背景画像を使用しています。containただし、 for を使用して Reflow に追加するとscale-x、作成した画像がそのサイズではないように見えます。それらのほとんどは、設計より少なくとも 200 ピクセル短かった。

したがって、私の質問は、各ブレークポイントにどのサイズの背景画像を使用する必要があるか、およびリフローを使用してこれに関するその他のガイダンスや、何か間違ったことをしているという提案です。

通常はcoverむしろ使用しますcontainが、画像は拡大縮小され、デバイスからデバイスへの必要なものが表示されません。

ありがとう

こんにちは、私はこのナビゲーションバーを持っています:

デバイスの画面が小さすぎて 3 つのボタンが表示されない場合は、ボタン「メニュー」を追加する必要があります。

このようなもの: http://img30.imageshack.us/img30/8634/o6c5.png

css にルールを追加する必要があることはわかっていますが、方法がわかりません。よろしくお願いします。

私は、メモリ効率の高い高速な JavaScriptの記述に関する記事を読んでいて、「リフローの最小化」セクションで、次のような個々の DOM 追加操作を行うことについて警告しています。

この関数の後に、著者は次のように書いています。

「各新しい div を要素に直接追加するだけで、 20 回のリフローが発生する可能性があります。」

だから作者はそうは言っていない。私はd3.jsを多用しているので、 githubのソース コードを調べて、コメントreflowや使用法があるかどうかを確認しましたDocumentFragment(ただし、これは他の手法で実現できます)。

私の質問は: d3.js がリフローを減らすために何らかの手法を採用しているかどうか、またはその最適化をブラウザーに任せているかどうかを知っている人はいますか?

ありがとう。

私の質問は簡単です、

要素のオフセット位置を取得しようとすると、chrome devtool タイムラインでリフローが表示されるのはなぜですか?

私はこれを読みました=>

IE では、offsetTop、offsetLeft、offsetWidth、offsetHeight、scrollTop/Left/Width/Height、ClientTop/Left/Width/Height、getComputedStyle()、または currentStyle

上記のすべては基本的にノードに関するスタイル情報を要求するものであり、それを実行するたびにブラウザは最新の値を提供する必要があります。そのためには、スケジュールされたすべての変更を適用し、キューをフラッシュし、弾丸を噛み、リフローを行う必要があります。

そこで、chrome devtool タイムラインを開きましたが、これを試しても再計算スタイル (紫色のもの) が表示されませんでした:

レンダリングを確認する唯一の方法は、要素のスタイルを変更することです:

ウィンドウの上部のスクロールを取得しようとするたびにリフローが発生することを期待していましたが、そうではありません:/

次のような数百の「行」要素があります。

ページに既にレンダリングされた後、 clientHeight を取得する必要があります。「clientHeight」プロパティがリフローを強制することを知っています。これは、非常に多くのリフローがあるため、パフォーマンスが低下します。ただし、それらは既にレンダリングされており、レンダリングされてから高さを照会するまでの間、サイズが変わらないことがわかっています。

高さを照会するときにブラウザーにリフローしないように指示する方法はありますか? さらに、Webkitインスペクタは次のように述べています。

そして、div は絶対配置された祖先内にあります。絶対配置された要素だけをリフローするべきではありませんか?

編集：

したがって、提供された答えは正しいです。このループがあったため、実際にはレイアウトを汚していました。

コードをこれに変更すると、問題が修正されました。