新UIについて

こんばんわ。先程新UIをリリースしました！何がどうなったのか簡単に説明するよ。

mikutterの従来のレンダリング方法

いままでのmikutter。見た目はリッチ。
動作は察してください。

今までのmikutterは、ウィジェット※1を綺麗に並べてタイムラインを実現していました。この方法だと、あらゆるウィジェットを使用することができるので、タイムラインのレンダリングがとても自由にできます。

※1…ウィンドウのパーツのこと

したがって、mikutterのタイムラインは他のTwitterクライアントのそれに比べてかなりリッチな部類だと思います。なかでも、アイコンオーバーボタン（アイコンにマウスカーソルを重ねるとボタンが出てくる機能）、ふぁぼられ、リツイート累積表示、リプライ宛先表示などのmikutterの代表的な機能は、この方法でタイムラインをレンダリングしたからこそ容易に達成できた、という背景がありました。

何が悪いのか

本来、ウィジェットは頻繁に追加削除されるものではないので（大体は作ったらそれでおしまいですよね）、ある程度タイムラインの流れが速いと、異常な速度でウィジェットの作成／削除／パッキングが行われます。
配置の自由度が高いぶん、こういった変化があったときの再描画のコストは馬鹿になりません。また、Ubuntuの最新版に入っているRubyGTKはとても古く（nattyには0.19.3が入っているが、最新は0.90.8）、大量のバグが含まれているのが現状です。そのようなAPIに頻繁にアクセスするので、ライブラリがSegmentation Faultしてmikutterが巻き添えになることがしばしばありました。

他のTwitterクライアントのレンダリング

夜フクロウ。
Linuxじゃない、Rubyじゃない、Gtkじゃない。
けどリストビューっぽいですね。

mikutterは他のTwitterクライアントと比較して、レンダリングが飛び抜けて遅いですね。説明は上記の通りだけど、ではどうしてそんなことをしたかというと、現在のmikutterは、とりあえず表示できるものを仮に作った段階だったのです。つまり、mikutterのUIは新たにつくり直す必要がありました。

では、他のTwitterクライアントはどうしているかというと、リストビューを使用していると思われます。

リストビューは、パーツが縦に並ぶことを前提にしているのでどうやら速いらしい。ソートオーダーなどの細かい話もGtkがやってくれるのでRubyでやるよりは早くなりそう。

しかし、じゃあリストビューにすればいいじゃない、と簡単にはいかない。というのも、この中に置けるのは、せいぜい画像と文字くらいだからで、新しいRendererを作成するにしても、今までのように好きなウィジェットを思いのままに設置するとはいきません。

Cairo＋リストビュー

新UI。かなり高速になったが見た目はそんなに変わらない。

じゃあ、全部画像にしたらよくね！？という奇想天外なことを思いつきました。画像だったらすきにレンダリングできるけれど、キャッシュすれば速さもでるんじゃねーのと思ったわけです。

リストビューは、任意のRendererを設定できるので、今回は実際にTLを描画するやつをMiraclePainterという名前にしました。TLの先まですべてミク色に染めていただきましょう！！！

で、リッチな表示ができないとか言ってたけど蓋を開けたら右のようになってます。ついでだから微妙にマイナーチェンジしましたが。これがどの程度速くなったかは、実際に起動してもらったほうがよさそうなのでここでは書かないけれど、

• ボトルネックになってた部分は１００倍くらいの効率のアップ
• 起動時間は２秒
• 新しいタブを作ったりした時にブラックアウトすることもなくなった
• 入力中に固まってイライラすることもなくなった
• RubyGtkのAPIを叩く回数が減ったので、Segmentation Faultの確率が減るかも！？

と、圧倒的な進化を遂げました。CPU使用率も大幅に減ったので、いままで遅くて使えんと言っていた人もつかえるようになるんじゃないかな。

ただそのためには、ショートカットキーなどの処理をもっときめ細かにやっていかないといけないと思っていて、例えば横のタブにフォーカスとか、リプライ後のフォーカス移動とか、そういうところに気を配らないとなぁ、と思ってます。

現在この最適化は、0.0.3.5 ウィークリーリリース版に適応されています。これからバグを取ったり最適化をする段階だけど、興味がある人は是非！！！