通知が 1日に 3～4通のメールのみの状態で、
満充電から 12時間でおよそ 25% の消費でした。
他に特別な操作を行わなければ Apple Watch もちょうど二日間持ちます。
バッテリーの持ちは Android Wear とほぼ同等といえそうです。

心拍数の計測には若干時間がかかります。
ポラールのような胸に巻くセンサーとは違い、ワークアウト中でも
リアルタイムにモニターできるわけではないようです。

その代わり Apple Watch 以外に特別なセンサーが不要なので使い方は非常に簡単。
普段通り通り身につけているだけでよく、ワークアウトの結果に
平均心拍数が記録されているのは便利に思いました。

Android Wear も 5.0.2 から 5.1.1 への更新が行われました。
時計画面のタップでアプリの一覧になり、これまでとは比べ物にならないほど
アプリを起動しやすくなっています。

また、今までアクション経由でしか呼び出せなかったストップウオッチや
タイマーも、アプリリストに並んでアイコンから起動できるようになりました。

リアルタイムに更新可能な地図アプリが入ったのも嬉しい変更点です。
これまでナビ機能があっても、ボイスコマンドを使わなければ
呼び出すことが出来ずわかりにくいものでした。
地図アプリによってすぐに現在地の確認ができます。
そのまま周辺スポットを調べたり、そこまでのルート指定もボイス無しに
できるようです。

関連エントリ
・Apple Watch を使ってみた, Android Wear との比較など

Apple Watch を手に入れたので数日間使ってみました。
印象としては、これまで使っていた Android Wear など Android ベースの
スマートウオッチとはかなり違うということ。
特に感じたのは最初からできることが多い点と時計としての安定感です。

左から
SmartQ Z Watch, Apple Watch Sport 42mm, Android Wear LG G Watch
大きい方の 42mm モデルですが、並べると他のスマートウオッチよりも小さめです。

● アプリと操作

Android Wear は単独で専用アプリが動くものの、標準の UI は音声認識できる
通知特化デバイスといった位置づけでした。

通知だけのアプリもありますし、Android Wear はほとんどの場合
設定などの操作をスマートフォン側のコンパニオンアプリで行います。

全体的に時計側ではあまり複雑な操作をさせたくない印象です。
インストールしたアプリの起動も深いメニューの奥底で、
隠してあるのではないかと疑ってしまうレベル。

Apple Watch はまず HOME 画面からしてアプリのアイコンが並びます。
デジタルクラウン (右サイド上のボタン) を押すだけでこの画面に戻ることが可能。
通知を受けるだけでなく、アプリを使って欲しいのだということが明確にわかります。

Apple Watch 側でできる操作が多く、小さい画面ながら物理ボタンの併用によって
操作性が工夫されています。

・タッチ画面 (マルチタッチ操作はしない)
・タッチ画面の強い押し込み (選択メニュー等)
・デジタルクラウンの回転 (スクロール, ズーム)
・デジタルクラウンの押し込み (HOME, 戻る, Siri)
・サイドボタン (フレンドリスト, 電源)

Android Wear の場合統一されている共通操作は画面の左から右へのスワイプです。
これが Android の “戻る” ボタン 相当で、どの画面でもこの操作ができないと
Android Wear アプリの審査が通りませんでした。
(通らなくてもストアには公開できます)

Android Wear の機種によってはサイドに物理ボタンを持っているものもありますが、
スリープや長押しで設定画面が呼び出せるだけです。
ボタンがない機種も存在するのでアプリの個別操作には活用されていません。

● 通知とアプリ

Android Wear の基本は通知の仕組みを使ったカード型のビューアです。
Gmail も新着が届いて返信やアーカイブ等の操作ができますが、
通知扱いなので一度消すと読み返すことができなくなります。

さらに厄介なのは、アプリからの情報を通知領域に表示するものがあることです。
通知画面とアプリ画面の違いがわかりにくいこと、通知同様に消せることと
アプリに容易に戻れないなど、慣れるまでは混乱しがちです。

Appel Watch は通知とアプリは別れておりスマートフォンに似ています。
メールの通知は消せますが、アプリを起動すれば能動的に選択してメッセージを
見ることができます。

また時計や HOME 画面に切り替わっても、デジタルクラウン (HOMEボタン相当) の
ダブルクリックで直前まで使ってたアプリに戻ることが可能です。

● 内蔵アプリ

Android Wear を手に入れた当初は、何ができるのかよくわからなかったのが
正直なところです。
基本的には拡張子の関連付けのように、アクションに対して機能を割り付ける
仕組みとなっています。
アクションからのみ呼び出せるものもあり、必ずしもアプリの一覧に
アイコン並んでいるわけではありません。

Apple Watch は機能が HOME 並んでいるので非常にわかりやすいといえます。
メール、マップ、フォト、カレンダー、ミュージックその他、さまざまな
内蔵アプリが用意されています。

その反面、サードパーティ製のアプリは今のところ iPhone との接続が必須と
なっているようです。
Bluetooth か Wi-Fi どちらかが必要で、接続が切れるとアプリを起動することが
できなくなります。
内蔵アプリは接続がなくても動きます。

この辺 Android Wear は制限がなく自由度が高くなっています。
UI 以外は Adnroid API そのままです。NDK も使えます。

● 腕時計として使う

Android ベースの Z Watch は、任意の Android アプリが動くので出来ることが
多い反面、時計としての使い勝手はそれほど良いものではありませんでした。
画面の常時点灯はできず、腕の動きでスリープ解除できるものの認識はいまいちです。
一番問題だったのはスリープ解除しても時刻の表示が更新されていないときがあり、
時計としての信頼性に欠けることです。

Android Wear は Ambient Mode があるので、時計画面を常時表示させて
おくことができます。

ただし機種によっては常時 ON にできないものもあります。
またバッテリーを優先したい場合は普段画面を消しておくことも可能。

画面タッチだけでなく腕の動きでも点灯しますが、必ずしも意図した通りに
反応してくれるとは限りませんでした。
なかなか点灯せず、結局画面をタッチすることもしばしば。
動作から画面点灯までの時間は一定ではなく、反応にはばらつきがあります。
時計として使うなら常時表示の Ambient Mode の方が確実です。

Apple Watch の時計は残念ながら常時点灯ではなく普段は画面が消えています。
ところが腕につけている場合、非常に良いタイミングで画面が点灯してくれます。
時間を見ようと腕を上げると即座に画面が現れるため快適に時刻を確認できます。
点灯までの反応速度は安定しており今のところストレスはありません。

● 単独で Music Player として使ってみる

Android Wear では 5.0 から単独で音楽プレイヤーとして使えるようになっています。
ただし Google Music が必須で日本では使用することができませんでした。
以前作った↓アプリによって、単独でオフラインプレイヤーとして使うことができます。
Bluetooth ヘッドホンが必要。

・Music Player2 for Android Wear
・Muisc Player for Android Wear

Apple Watch もオフラインプレイヤーに対応しているので試してみました。

　1. iPhone で Apple Watch アプリ起動
　2. マイウオッチ → ミュージック から同期するプレイリスト選択
　3. Apple Watch を充電器に接続 (同期転送は充電中のみ行われる)
　4. 転送完了したら Apple Watch の 設定→ Bluetooth からヘッドホンをペアリング

　5. Apple Watch の「ミュージック」アプリ起動して、画面を押しこむ
　6. ミュージックソースの選択があるので「Apple Watch」を選ぶ

　7. 同期転送したプレイリストを再生。

単独で再生可能で iPhone との接続が切れていても問題ありません。

注意点としては、一度ペアリングに失敗するとデバイスを認識できなくなる場合が
ありました。一覧に Bluetooth ヘッドホンが現れない場合、または再接続に
失敗する場合は Apple Watch の電源を一旦切ってから入れ直すことで改善しました。

● iPhone が必須

Android Wear は Android OS 4.3 以降の OS 制限があるものの、
スマートフォンでなくてもペアリングして使うことが出来ました。
Nexus 7 などのタブレットでも問題なし。

Apple Watch は iPhone 専用なので iPad や iPod では使うことができません。
対応しているのは iPhone 5 以降。iPhone 5/5c/5s/6/6Plus の 5機種のみです。

● iPhone との接続と Wi-Fi

Android Wear は対応スマートフォンと Bluetooth で接続を行いますが、
Apple Watch は iPhone との接続に Bluetooth と Wi-Fi が併用されているようです。

最初の認識は Bluetooth ですが、途中で Bluetooth だけ OFF にしても
iPhone との接続は切れません。
ルータが無い場所では Wi-Fi だけでは接続を維持できなかったので、
直結ではなくルータ経由のようです。

● 最後に

価格が高いこともあり、当初はあまり購入に乗り気でなかったのですが、
実際に使ってみて非常に良く作りこまれていると感じました。
高性能スマートウオッチなのに、腕時計としてきちんと使い物になることに
少々驚いています。
全く期待していなかったせいもあるのかもしれません。

かつて通常の携帯電話からスマートフォンに乗り換えるタイミングが訪れたように、
コストと性能のバランスが取れたら、自然にスマートウオッチに置き換わる時が
来るのでしょう。

バッテリー寿命など使っていくと不満はこれからいろいろ出てくるかもしれませんが、
今のところ気に入っています。
これまで普通の腕時計と Android Wear を併用していましたが、
Apple Watch なら一つで十分だと感じました。

関連ページ
・Smart Watch 一覧

関連エントリ
・Android Wear 単体で音楽再生を行うアプリ (2)
・Android Wear 5.0 Watch Face API 対応と互換性
・Android Wear Sony SmartWatch 3 SWR50 は速い
・Android Wear 3D のアナログ時計 (Watch Face)
・Android Wear にゲームを移植
・SmartWatch 関連エントリ

オプション扱いですが Direct3D12/Direct3D11.3 では新たに
ASTC 圧縮テクスチャがサポートされています。
ASTC は OpenGL ES 3.0 で導入された新しい圧縮形式です。
DirectX では BC 系以外では初であり、モバイルからの逆輸入になります。

・MSDN DXGI_FORMAT

これで dds ファイルに ASTC 画像を格納できるようになりました。
下記ページの一覧表に DXGI_FORMAT_ASTC_* を追加しています。

・圧縮 Texture

ASTC について以前の解説

・OpenGL 4.3/GLES 3.0 次の圧縮テクスチャ ASTC

● 64bit 単位の圧縮

圧縮テクスチャの多くは 4×4 block 単位で 64bit に圧縮します。
例えば下記のフォーマットは 64bit です。

DXT1(BC1), ETC1, ETC2(RGB), ATITC(RGB), PVRTC 4bpp, PVRTC2 4bpp

64 bit/16 pixel なので 1pixel あたり 4bit (4bpp)。

DXT3/5 (BC2/3) や ETC2-EAC などアルファ付きフォーマットは 128bit 8bpp ですが、
内部的には 64bit/block の構造が 2個並んでいるだけです。
処理の単位はあくまで 64bit になります。

DXT1 (BC1)
+-----------+
|COLOR 64bit|
+-----------+

DXT3 (BC2)   DXT1 + A4
+-----------+ +-----------+
|COLOR 64bit| |ALPHA 64bit|
+-----------+ +-----------+

DXT5 (BC3)   DXT1 + BC4
+-----------+ +-----------+
|COLOR 64bit| |ALPHA 64bit|
+-----------+ +-----------+


ETC2
+-----------+
|COLOR 64bit|
+-----------+

EAC (EAC-R11)
+-----------+
|RED   64bit|
+-----------+

ETC2-EAC     ETC2 + EAC
+-----------+ +-----------+
|COLOR 64bit| |ALPHA 64bit|
+-----------+ +-----------+

EAC_RG11     EAC + EAC
+-----------+ +-----------+
|RED   64bit| |GREEN 64bit|
+-----------+ +-----------+

● 128bit 単位の圧縮フォーマット

64bit/block を第一世代とすれば、BC6H/BC7 は 128bit/block の第二世代の
圧縮テクスチャに相当します。

64bit では 16個の index 値がエンコードスペース大半を占めるので
あまり複雑なアルゴリズムを選ぶことができませんでした。
追加の圧縮情報が増えるとベースカラー (Endpoint) の bit を減らすしかないので
カラー精度と圧縮アルゴリズムのどちらを取るかトレードオフになります。

128bit/block ならスペースに余裕があるためフォーマットの自由度が増します。
BC6H/BC7 はこの追加容量を、HDR 対応化や高画質化に割り当てています。
8～14 種類のアルゴリズム選択、Partition 分割による複数の Endpoint セットなど
より複雑なエンコードが行われています。

画質が向上する反面 BC6H/BC7 は容量が増えます。
単純な RGB カラーでは DXT1 の 2倍なので、圧縮率を優先する場合は BC7 は
あまり出番が無いかもしれません。

● 圧縮率とブロックサイズ

block あたりの容量を減らさなくても、block サイズを増やせば圧縮率が上がります。
その代表例が PVRTC/PVRTC2 の 2bpp フォーマットです。

PVRTC は 64bit/block ですが、block サイズを 8×4 に広げることで 2bpp まで
圧縮することができます。
ただしこの場合 index 数が増えるためピクセルの階調が減ります。
index は 8×4 = 32個必要なので 1pixel あたり 1bit になるためです。

● ASTC

ASTC は 128bit/block の第二世代に属し、128bit エリアをフルに使った
複雑なエンコードを行います。
しかしながら block サイズを可変にすることで、同時に高い圧縮率も実現しています。

4×4 block の場合は BC6H/BC7 同様 8bpp ですが、
6×6 block ではおよそ 3.6bpp、
8×8 block では 2bpp と
目的に合わせて圧縮率を選ぶことができます。
もちろん圧縮率を上げると画質はそれなりに下がります。

・OpenGL ES 3.0 / OpenGL 4.3 ASTC 圧縮テクスチャの比較

ASTC の注意点は、これまで絶対安全だった 256×256 や 512×512 といった
2^n サイズのテクスチャが必ずしも割り切れないことです。
例えば ASTC 6×6 の場合、 256×256 サイズのテクスチャも内部的には
258×258 でデータを持つことになります。

テクスチャローダーでは注意が必要です。
bpp が割り切れる整数値にならないことと、テクスチャサイズで端数が生じることから
ASTC 対応のためにいくつかの手直しが必要になるかもしれません。

関連ページ
・HYPERでんち: 圧縮 Texture 一覧
・HYPERでんち: 解説記事一覧

関連エントリ
・iPad Air 2 (Apple A8X) の GPU
・OpenGL ES 3.0 / OpenGL 4.3 ASTC 圧縮テクスチャの比較
・OpenGL 4.3/GLES 3.0 次の圧縮テクスチャ ASTC
・Direct3D11/OpenGL 圧縮テクスチャ BPTC, BC6H/BC7 の詳細構造 (2)

NexusPlayer は Chromecast と同様の使い方もできます。
PC (Chrome) やスマートフォン・タブレットからストリーム系アプリの
コントロールをしたり、画面を転送することが可能です。

Chromecast に関しての以前の記事はこちら
・Chromecast で C++ アプリを走らせる。Emscripten のゲームを動かす

Chromecast と違い Android TV は Wi-Fi 設定など本体で操作可能で
IP アドレスの確認も自分でできます。
そのためか Chromecast のようなセットアップアプリは不要で、
ネットに繋がればすぐに cast 可能な状態になっているようです。

USB で直接 PC と接続できるため、Cast アプリのデバッグもしやすくなっています。
自前の Custom Receiver を走らせるための手順は下記の通り。

1. Google Cast SDK の Developer 登録を行う。
　・Google Cast SDK Developer Console

2. Nexus Player のシリアルナンバーを Developer Console に登録
　・設定→端末情報→シリアル番号 で確認可能
　・登録後 15分待つ必要あり

3. Google Cast の Developer Mode を有効にする
　・設定→Google Cast→デベロッパーサポート を「はい」に変更
　・ここで一旦再起動する

4. Developer Console で Application ID を作成
　・任意のアプリケーション URL を登録して Application ID と関連付ける

5. Application ID を自分の sender App に埋め込む

Android Application 同様 adb 接続で logcat の確認ができますし、
Chromecast 同様 PC の Chrome Browser で Inspect の表示ができます。

Chromcast よりもずっとプロセッサのパワーがあるため、
以前作成した ChiRaKS も十分な速度で動くようになっています。
Chromecast と互換性がなくなってしまうので仕方ないのかもしれませんが
WebGL は動きませんでした。

関連エントリ
・Nexus Player を GamePad＆Mouse で使う、他
・Chromecast で C++ アプリを走らせる。Emscripten のゲームを動かす

Google の Android TV 端末、Nexus Player を使ってみました。
UI は一般の Android とは大きく異なり TV を意識したもの。
操作は付属のリモコンを使うので Apple TV に似ています。

・Google Nexus Player

大きく異なっているのは単体でアプリが動作することで、Google Play Store からダウンロードできます。
ただし専用＆対応アプリしか出てこないらしく検索してもタイトルは多くありません。
HOME に並んでるものもゲームとムービー等のコンテンツのみで実用系アプリは無し。
Chrome や GMail なども無く、検索でもこの辺りのアプリが見当たりませんでした。

micro USB 端子があるので PC につなげば adb 接続できます。
開発者メニューを有効にするには設定の端末情報から「 ビルド 」を何度も選択する必要あり。
USB 経由で install した場合は普通の Android アプリも動くようです。
ただし HOME 画面にはアイコンが表示されないため、実行には少々手間がかかります。

　1. 設定 → アプリ → ダウンロードしたアプリ
　2. 一覧から選択してから「開く」

HOME画面に表示させる場合は intent-filter の設定が必要です。

application に isGame=”true” があるとアプリではなくゲーム側に分類されます。

通常の Android アプリを走らせた場合タッチ操作はできませんが、
vfpbenchmark のように標準の UI を使ったものはリモコンだけで操作できました。
(vfp benchmark の結果はこちら)

また USB Host が有効なので、タッチ操作が必要なアプリでもマウスを繋げばそれなりに使用することが出来ます。
BACK や HOME ボタンはないので、マウスの場合もリモコンは必要になります。

同様に USB を使った接続では PS3 や Xbox360 (USB版) のゲームコントローラも使うことが出来ました。
この辺りも通常の Android 端末と同様です。
専用のゲームパッドがなくてもひと通りゲーム操作できます。
ただし USB 接続は adb と併用できないので、ゲーム開発にはワイヤレスのコントローラが欲しくなります。

下記追加しました

・VFP Benchmark Log
・CPU/GPU OpenGL ES Extension (Mobile GPU)

GPU は Intel HD Graphics ではなく Apple A7 世代と同じ PowerVR G6430 です。

関連エントリ
・Android 5.0 Nexus Player x86 と対応 ABI
・iOS7 対応 SteelSeries Stratus ワイヤレスゲームコントローラー
・Android 用ゲームパッド BUFFALO Zeemote JS1 H
・Android 3.1 と GamePad のイベントの詳細 (2)
・Android 3.1 と GamePad のイベントコード