3

カラムナイザー jquery プラグイン ( https://github.com/adamwulf/Columnizer-jQuery-Plugin ) の軽く削除されたバージョンを使用して、使用する「列」に変換する大きなテキストが多数あります。別のプラグイン。Columnizer は、列化されるチャンク内にフローティング コンテンツがない限り、私の目的には問題ありません。

Chrome、FF、および IE10 はすべて、ほとんどの場合、純粋なテキストまたは画像とその他の単純な html が混在するテキストで同様のパフォーマンスを発揮します。ただし、フローティング コンテンツ (この場合は画像) を含めると、状況は劇的に変化します。

Big Book w/ Images、作成された約 700 列
試験条件 Firefox (秒) Chrome (秒)
-------------------------------------------------- ---------------
通常のブック ビルド (イメージ、フロート) 31.5 1254.2
上記と同様、ただし画像なし 23.2 18.9
画像あり、フローティング画像なし 25.1 24.7
浮かせた画像が少ない 27.6 1010.9
「p」以外のすべての画像とタグを削除します 21.3 18.9

ご覧のとおり、それは非常に大きな違いです。(私はビルドをキャッシュしますが、ブラウザーと OS の組み合わせごとにレンダリングが若干異なるため、最初に「主要な」ブラウザーでそれぞれをビルドする必要があります。iPad 上の Safari でこれをビルドするのを待つまで、あなたは生きていません。こと -- Windows のクロム番号に 4 を掛けます。)

だから私の質問: firefox は尋ねられずに「正しく」行っていることは何ですか? また、他のブラウザーでそれを模倣するためにコラムライザーのコードを作り直すにはどうすればよいですか? Columnizer は、数千回 (この本の場合は 100,000 回以上だと思います) の追加を行うという点でかなり「汚い」ものであり、これは明らかにクールではありません。ドキュメントフラグメントを使用していますか? 他のトリック？

Columnizer では、スタイルを正しく適用できるように (つまり、"display:none" がなく、終了時にトグルする)、宛先コンテナー (コンテンツ フローを実行する場所) が dom 内にある必要があります。私の CSS では、推奨されるように、これを position:absolute、visibility:hidden に設定しています。FF は、この属性セットを他のブラウザーとは異なる方法で表示する必要があると考えています。または...？

プロセスの最後に、フォント レンダリングのわずかな違いを除いて、出力はブラウザー間で同じであることに注意してください。

4

1 に答える 1

0

これが私自身の質問に答えるとは絶対に確信していませんが、私は物事をより良くしました。ある意味で私にとって十分な答えです. 私のソリューションがなぜ違いを生んだのか、実際に知りたいです。

背景:本のテキストの「事前フォーマット」をできる限り PHP で行っています。これは、サーバー側でクリーンアップやその他のありふれたテキスト作業を行う方がはるかに高速であるためです。次に、このクリーンアップされた html のチャンクが div にスローされます。これを列にまとめます。このコンテナー (「raw」と呼びましょう) と列の空の宛先コンテナー (「dest」) は dom にある必要があるため、この CSS を「raw」と「dest」を持つラッパー div に配置します。子供として：

position: absolute; 
top: -2000px;
left: -2000px;
width: 700px;
height: 500px;
visibility: hidden; 
overflow: hidden;

これにより、ページから 2 つの div が「削除」されましたが (私たちの目玉に関する限り)、それらはまだ dom 内にあるため、Columnizer はそれらを操作できます。

うーん: Firefox では、フロートかどうかにかかわらず、これで十分に機能しました。しかし、Chrome、Safari、および IE では...最初の質問の表を見てください。うん。

しかし、「raw」に「position: absolute」を追加することで、他のブラウザのパフォーマンスが劇的に向上しました。FFほど速くはありませんが、それほど遅れていません。1200 秒以上かかる代わりに、書籍全体を表示する際に Chrome に 40 秒かかるようになりました。iPad は氷河期ではなく、数分かかります。

なんで？それは私には謎です。準備中に、列化器内の関連ビットと思われるものは次のとおりです。

...
var $sourceHtml = $('div.raw'),
    $cache      = $('<div></div>'),
    $inBox      = $('#dest'),
    $destroyable, $col;
...
$cache.append($sourceHtml.contents().clone(true));
$inBox.empty();
$inBox.append($("<div style='width:" + options.width + "px;'></div>")); 
$col = $inBox.children(":last");
$inBox.empty();
try {
    $destroyable = $cache.clone(true);
} catch(e) {
    $destroyable = $cache.clone();
}
...

キャッシュとして作成された空の div は、まだ何も追加されていないため、この時点では DOM 内にある必要がありますが、HTML ページの外側にあります。え？そのため、操作されているため、ページを再描画する必要はありません。

私の中途半端な理論は、FF はそれを認識しますが、他のブラウザーは認識せず、$destroyable がページの塗りつぶされた領域内にあると見なし、おそらく body タグに追加するか、「ラップ」することさえあるというものです (ただし、 Chrome のインスペクタではそのようなことは示されませんでした)?

ノードが $destroyable から取り除かれ、作成される列に追加されるため、他のブラウザーは $destroyable が変更されるたびにページを再描画します。ブロックとインラインのもので高速ですが、フロートが追加されると高価です。

しかし、その中途半端なアイデアに穴を開けると、「position: absolute」を $destroyable に追加しようとしても違いはありません。元の「生の」divにその属性がある場合にのみ、速度が上がります。

とにかく、大酒飲みと無知に戻りましょう。辛抱強くため息をついて、できればこれを教えられる瞬間にしてください！

于 2013-11-08T09:38:39.933 に答える