1

固定サイズの (自動的に大きくならない) テキストエリアを使用して、HTML でシンプルな (リッチではない) テキスト エディターを実装しています。そのテキストエリアに合わせてテキストを分割するページネーションシステムを作成しました。relativelay の大きなテキスト (20 ページ = 20 テキストエリア) の場合、関数はこれらの 20 ページに対して合計で約 100 ミリ秒かかります (テキストが少ない場合はそれより少なくなります)。ロジックは次のようになります。

function paginate() {
    clienth = textarea.clientheight;
    while (maxTextSize>minTextSize+1) {
        textarea.value = text;
        // a binary subdivision algorithm which runs in logarithmic time
        if (textarea.scrollheight>clienth) {
            text = newsmallertext;
        } else {
          text = newbiggertext;
        }
        maxTextSize = newvalue1;
        minTextSize = newvalue2;
    }
}

そのため、約 14 KB のテキスト (19 ページ) の場合、この関数は 187 回 (ページあたり 10 回) 呼び出され、Firefox では約 100 ミリ秒、Chrome と Opera では約 60 ミリ秒、IE では約 200 ミリ秒かかります。これらの 100 ミリ秒のうち、約 40 ミリ秒はテキストをテキストエリアに割り当てるために費やされ ( .value = blabla )、残りの 60 ミリ秒はスクロールの高さが clientheight より大きいかどうかを確認するために費やされます。つまり、時間の 99% がそこで費やされます。

それはあまりないように見えますが、そうです。なんで ？それに応じて新しいテキストを適用するために、ユーザーがテキストエリアに入力する（キーを押す）たびにその関数を呼び出す必要があるためです。ユーザーは、文字、バックスペース、削除、Enter キーの入力などを入力できます。そのため、キーダウンごとに paginate 関数を再度呼び出して、テキストエリアに収まる新しいテキストを計算します。押されたキーごとに100ミリ秒の遅延があるため、入力が非常に遅くなります。

したがって、テキストをテキストエリアに割り当てるか、スクロールの高さをチェックするための最適化があるかどうか、またはこれとはまったく異なる方法があるかどうか疑問に思っていました。

すべての提案を前もってありがとう。

テキストエリアを自動的に拡大することを提案しないでください。要件には含まれていません。

編集: while() ループの動作をより明確にしました。

4

0 に答える 0