Reloading Optimization #2

別のアプローチからも高速化を施してみよう。お知らせによると、2018/11/09 付でリロードの高速化が施されたとある。つまり、ふたばが標準で返してくる html における [リロード] ボタンの動作が変更されたということだ。

リロードボタンを押した時、従来はまず HEAD リクエストを飛ばして、更新されていたらページ全体をリロードという形になっていた(たぶん)が、11/9 の変更ではこのページ全体のリロードに代えて、XMLHttpRequest で [cci]futaba.php?mode=json[/cci] 云々をリクエストして、新しく増えたレスの情報だけを json 形式で受け取るようになっている。これによりまず転送量が劇的に減る。転送量が減ることでレスポンスタイムも短くなる。これは立派な差分取得 API と捉えられるので使わない手はない。

ということで組み込んでみた。ここで重要なのは、リロードの手段が 2 つになるということだ。差分形式で得られるのは新着レスとそうだねの全データのみであり、ID 付与やレス削除を同期するにはフルリロードしなければならない。なので、対応する UI としてはまず従来の [続きを読む] リンクの隣に、[差分で続きを読む] リンクを置くことが考えられる。あるいは逆にデフォルトを差分読み込みにして、[フルで続きを読む] でもいい。しかしこれはユーザに対していちいち気にしながらリロード手段を振り分けることを強いているわけで、あまりいい UI ではないかもしれない。自分を含めて、「」もとしあきもそんなに賢くない。

従ってあくまでリロードボタンは 1 個だけで、赤福プラス側がよきに計らって適宜フルと差分を切り替えるのが良いように思える。例えば最後にフルリロードした時刻を覚えておいて、そこから n 分経過するまでは差分リロードとかでどうか。n は定数でもいいし、スレッドの勢いか何かから動的に算出する形式でもいいだろう。

とそういうわけでそうしてみた。n は設定可能な定数にした。デフォルトは 2 分間隔でフルリロードする。この状態でいつもどおりスレッドを見ると、転送量はだいたい 90% 削減できるようだ。もちろん読み込みも速い。すごい。

このあたりの話の流れは、むしろ懐かしい。というのは12年くらい前に Opera 版の赤福プラスに続きを読む処理を加えた際、もともとリクエストヘッダに Range を追記しておんなじような転送量削減の措置を施していたからだ。ところがほどなくして Apache の Range の取り扱いに関して脆弱性が発覚してしまった。そんなわけで双葉の鯖もパッチが当てられ、Range は無事無視されるようになったのであった。がっくり。

Reloading Optimization

続きを読む処理の高速化。まず続きを読む際に何をするかを列挙してみよう。

  1. ふたばから html を読み込む
  2. html のうちレス群以外を xml に変換する
  3. xml を元に、スレ本文の諸々及びその他のバインディングを更新する
  4. html のうちレス群を xml に変換する
  5. xml を元に、読み込み済みのレス群の以下の項目を更新する:
    • 書き込んだ人による削除、スレッドを立てた人による削除、強制的なIP開示、なー
    • ID の開示
    • そうだねの増減
  6. 新しく増えたレス群を html に変換し、そのフラグメントを DOM に追加する
  7. 全レスに対して、ID の出現頻度をカウントし直す

この処理の内で現在ボトルネックになっているのは 5 と 7 だ。それぞれの処理をプロファイルしながら地道に高速化していく必要がある。

というわけで高速化した。1500レスくらいのスレッドで続きを読む全体の処理に 1 秒ちょいくらいかかってたのが、300msくらいになったのでだいたい 3 倍くらいか。あとは 4 も 100ms ほど時間がかかるのだがまあこれはしかたないかな。

あと関係ないけどついでに may とかで、添付された画像のファイル名を引用する習慣があるようなのでそういう形式の引用にもポップアップするようにした。

Let the box be light #2

lightbox を一新した後、コメントにクリックするとCPUパワーを専有してしまうというバグが報告されたのだが、なかなか再現できなかった。そもそも lightbox の中に CPU を専有しそうな重い処理がない。

が、クリック時に 200ms ほどやけに重くなる現象は再現できた。画像のドラッグ時にテキストが選択されることがないように pointerdown/pointerup で [cci]document.body.style.userSelect[/cci] を操作しているのだが、これがリフローを呼び起こすらしく同時に使っている [cci]getBoundingClientRect()[/cci] と相性が悪いようだ。

userSelect を none にするのはドラッグ時ではなく lightbox 実行時全体にすることでこれを回避できた。もちろん副作用としてテキスト(倍率とか)を選択できなくなったがまあ許してくれるねグッドトリップ。

CPU 専有現象自体は Vivaldi 特有のものなのか環境によるものなのかは不明。以前、あべ☆アニを作ってた際にも同じようなことがあったので、Vivaldi 自身がなんかやってるのかなあ…?

Difference between notices #2

まず diff を取る対象はマークアップレベルのテキストにした。ただし a 要素の href 属性以外は全て削ぎ落とされる。

また diff ライブラリとしては jsdifflib を利用するようにした。行単位の比較だし、diff 本体とプレゼンテーションのためのコードが分離しているのも都合がいいし、10KB ちょいとコンパクト。

というわけで注意書きの変更を検知すると、window.alert() でその旨を通知したのち自動的に注意書きパネルが開き、以下のように変更点が表示される:

多分初見で意味が分かると思うけど、赤背景で打ち消し線が引いてあるのが変更後に削除された行、緑背景が追加された行だ。

Difference between notices

ふたばの画像掲示板では送信フォームの下部に様々な注意書きを表示しているが、赤福プラスはロードした際にその注意書きの内容を覚えて保持しており、n キーを押すとパネルに注意書きが表示される。

さて、リロードした際にリロード前後の注意書きの内容を比較して、差異があったらそれを通知したい。できれば加えて、何が増えたのか減ったのかをグラフィカルに表示したい。つまり、diff の結果を表示したい。ところが、この diff のアルゴリズムというのは簡単なように見えて恐ろしく難しくて、それだけで1本論文が書けちゃうほどのものだったりする。それを真面目に実装するのも大変だし、既存のライブラリを組み込むにも、下手すると赤福プラス本体よりデカいとかありうる。

さらに、diff 自体の難しさと並行して、diff の対象をマークアップの段階にするか、人が読んで意味を取れる文章の段階にするかという問題もある。前者にすると、html マークアップ内の属性の変化も検知できるが、それがユーザが欲してる情報かどうかはやや疑わしい。例えば Chrome に ScriptSafe というエクステンションを入れると副作用としてありとあらゆる要素に ss-なんちゃらという属性を付けて回るが、この変化も検知してしまう。しかしこれはユーザにとってはどうでもいい情報だ。それを通知されても困る。

一方で後者、つまり各要素の内容だけをフィルタした結果にすると、例えば a 要素の href 属性と言った、割と重要な情報も見逃してしまう恐れがあるのである。どちらに振っても良い結果にならない。

どうするか。

Kenya Television Network #3

というわけで私的な環境におけるキーバインディングを整理したのだが、実は赤福プラス自身も textarea においていくつか Emacs ライクなショートカットを定義している。

でもそもそもこれ、いるんだろうか。textarea にショートカットがたくさん用意されていないと死んでしまうような輩は、そもそも自分でシステムレベルで有効な環境を構築している気がする。

まああっても害になるものではないし、残しておくかな。とりあえず設定にそういったショートカットを有効にするかどうかの項目だけ追加しておくことにしよう。

ところで javascript から textarea 内のキャレット位置を変更するには、selectionStart/selectionEnd をいじる他に、Selection#modify() がとても有用なのだが…どうもこれ、Firefox だと全然動かないみたい。63.0 on Linux、63.0.1 on Windows10 の両方で動かない。リファレンスを自分とこで用意しておきながら動かないってどういうことなんだろう。

Daikuuji

たまに虹裏では複数の「」が1文字ずつレスをして大空寺あゆ(・▽・)萌えっ!と叫んだり叫ばなかったりする。

で、完成すると(あるいは完成しなくても)適当なタイミングで「○○完成してるの初めて見た」的な締めになるわけだが。この時の○○が、せいぜい10文字程度ならその場で打ち込むのだけど、もっと長い何十にも続いたレス群の場合に困るのである。いちいち1文字ずつコピペで持ってくるのも面倒だし、さりとて打ち込み直すとタイポをしてしまう可能性がある。

というわけで

このように対象になる箇所を大胆に選択した後、出てきたメニューのうち「大!空!寺!」を選ぶ。すると、日付など必要のない部分はスキップし、コメント部分だけを抜き出した上で連結し、コメント欄に出力する。

収集されるテキストは、コメントを格納する div の直接の子供であるテキストノードのみである。エレメントノードは無視される。引用された行も span に囲まれているので、収集の対象にはならない。コメント部分が複数行だった場合は改行は削除される。

Let the box be light

画像をクリックするとデフォルトで lightbox 的な振る舞いをするのだが、これにはいくつか積み残しになっている点があった。

まず、画像を原寸表示させた際。このモードではマウスのドラッグにより画像のスクロールが可能なのだが、ドラッグしたままポインタをブラウザ外に持っていき、そこでボタンを離したりすると状態管理の不整合が起きてドラッグしてないのに画像がポインタについて来るみたいなことになってしまう。

これはつまりポインタのキャプチャをしていないからなのだが、何故していないのかと言うと、正確には覚えていないけど多分 Presto Opera にその機能がなかったんだと思う。これを直したい。

次に、全体表示から原寸表示モードに移行した際に拡大の原点がつねに画像の中心なのが不便。たとえば漫画なんかを1枚絵にした画像の場合に、原寸表示にしたあと上端へスクロールさせなければならないのが煩わしい。これを解決したい。

最後に、スマホで撮った写真など、本来90度回転して表示されるべきものが、そうなっていない場合がある。これに対応するため、画像の回転機能が欲しい。

というわけで、上記を解決するために書き直した。

回転にも transition をかけたのでやたらスムーズにくるくる回るのが面白い。

2番めの問題を解決するために、従来は画像をクリックすると lightbox を抜ける動作をしていたのだが、新しいバージョンではクリックしたポイントを原点に拡大縮小するようになった。lightbox を抜けるには画像以外の部分をクリックする必要がある。これはちょっと優しくない仕様変更かもしれない。

それと、画像のドラッグ時にいわゆる bounce-back 機能をつけたのだけど。これをつけると Apple に訴えられるんでしたっけ? ヤバイのかな。

* * *

とかなんとかやってたらまたふたばが全滅してるし…。

Is it ok with such a deciding!?

お名前や、題名や、メール欄や、コメントの内容が規定の長さを超えていたら警告する処理が長年動いてなかったのを修正。それぞれの要素の内容がそれぞれ設定されている最大の長さを超えていた時、警告を点滅表示する。

この警告はなんかよく分からないのだが、10年以上前 Opera 版赤福プラスを作る際、いもげにスレを立てて警告メッセージとして何がいいか「」に伺った時に出てきたものだ。当初は欲張って3桁ゾロ目のレスを採ると言ったのだが、さすがに1/100の確率なのでなかなか出ない。そういうわけでしびれを切らして次のゾロ目にしますと書き込んだ直後のゾロ目のレスが「そんな決め方でいいのか!?」だった。確か。