ひtoりgoと

ハードウェア組み立て編（→ 2015.8.29）の続き。

ハードは完成したので、Mac 側のソフトを作る。

データの作り方を考える

白か黒の二色しか表示できない白黒液晶なので最終的に Chibimo に送るデータは 1 と 0 が並ぶ単純なものだけど、問題はそれをどうやって作るかだ。

これがプリンタだったら Core Graphics のコンテキストを一枚作成してテキストなどの内容を順番に描画してビットマップを生成すると思う。でも今回は Mac の状況に合わせてリアルタイムに内容を変化させたいのでそれは面倒だし効率が悪い。

ということで選択したのは、Core Animation！ 2007 年に iPhone が発表されたとき、あらゆるものが当たり前のように 60 fps のスムーズなアニメーションで動いているのが衝撃的だったけど、それを可能にしていたのはこのフレームワーク。今では腕の上やテレビの中といったあらゆる場所で Apple 製品を支えている。

これを使うメリットは多い。iPhone App を作る感覚で表示内容を作れるようになるのだ。UI 用だけあってレイアウトやアニメーションが簡単にできるし、各レイヤーは GPU を使って合成されるので効率がいい｡（この程度の解像度なら描画コストなんて大したことないけれども。）

描画までの流れ

とはいえ通常は Mac や iPhone のスクリーンに表示するために使われるものであり、今回は AppKit や UIKit がやっていることを自力でやる必要がある。

データ送信までの流れを軽く説明すると、まずアプリケーション起動時：

1. OpenGL のコンテキストを作る。
2. IOSurface を作って 1 の内容と同期させる。
3. 1 のコンテキストに描画する CARenderer を作る。これにセットされた CALayer がルートレイヤーとなる。

そして 1 フレームごとに：

4. 2 の IOSurface のデータ（RGB 配列）をもとに白黒ビットマップを作成。
5. Chibimo が受け付けるような行ごとのデータを作成して送信。

この仕組みさえ用意しておけば、あとはルートレイヤーに好きなものを配置するだけでいいのだ。

表示を速くする工夫

最初に作ったバージョンでは画面の書き換えが遅いという欠点があった。表示内容が変化するたびに上から下まで順番にじわじわ書き換わっていくのが目に見えたのだ。iPod みたいに長い曲情報をスクロールさせようと思うとこれでは使い物にならない。

試行錯誤の結果、こんなことをやったらパフォーマンスが上がった：

• インターレースっぽく奇数行と偶数行を別々に送信するようにした。
• 最後に送信したデータと比較して、変更があった行のみ送信するようにした。

---

完成編（→ 2016.2.20）に続く...