毎回 canvas の内容を全部描く

http://cho45.stfuawsc.com/spectrum-performance/canvas-redraw-whole/

		ctx.putImageData(
			ctx.getImageData(0, 1, canvas.width, canvas.height - 1),
			0, 0
		);

上のようなコードで canvas 全体を 1px ずらして、最後の一行に新しいデータによる putImageData() をさらに行う。

ピクセルデータを直接シフトさせるやりかただと、一番ナイーブで実装が簡単だが実際のところかなり遅い。

35ms/render ぐらい。

2枚の canvas とっかえひっかえ追記で塗りつつ、DOM 的にエレメントを移動する

http://cho45.stfuawsc.com/spectrum-performance/canvas-double-dom/

canvas の 描画自体は1px * width だけを常に上書きする形で行い、全体のスクロールは DOM でずらす (ブラウザに再描画をやらせる)

わかりにくいので動画にするとこんな感じで、2枚の canvas 要素を margin で使って動かして、親要素で表示領域を制限 (overflow: hidden) してる。

4ms/render

WebGL でテクスチャ2枚をとっかえひっかえし、シェーダーでスクロールする

http://cho45.stfuawsc.com/spectrum-performance/webgl-double-textures/

2枚 canvas とやっていることはほぼ同じだが、canvas の代わりに WebGL のテクスチャを2枚定義し、DOM の代わりにシェーダーを使う。

0.6ms/render

毎回 canvas の内容を全部描く (drawImage)

@cho45 デバイスがなくてコードを試せてないのですが、putImageData+getImageDataではなくてdrawImageにcanvas自身を渡してずらして一行描くのだと速くなりそうですがどうでしょう。

— Mayuki Sawatari (@mayuki) October 5, 2015

と言われて、drawImage! そういえばそんなのも! という感じだったので試したらこれは十分高速だった。

• http://cho45.stfuawsc.com/spectrum-performance/canvas-redraw-whole-drawImage/

0.6ms/render で WebGL でやるのと変わらないぐらい。

肌感覚

canvas へ広範囲に putImageData の繰替えしをするより DOM で移動させたほうが圧倒的に早いのがおもしろかった。

WebGL は面倒くさい分たしかに高速で、2D でも可能な限り使ったほうがよさそうだけど、直接文字のレンダリングができないとか (canvas に書いてからテクスチャとして転送する必要がある)、API 的に面倒とか、GLSL というシェーダー言語を覚える必要があるとか、難点もある。

とはいえ、面倒なぶん自力でチューニング可能なポイントが多いのでおもしろい。

備考

もっと早くなる方法がありそうなら是非お知らせください。

https://github.com/cho45/spectrum-performance

localhost 自己証明書

ググって出てくるコマンドだと対話的インターフェイスでどうでもいい情報を入力する必要があってダルいので一発で自己証明書つくれるようにします。

#!/bin/sh

cd dev

CN=localhost

openssl genrsa -out server.key 2048
openssl req -new -key server.key -out server.csr -subj "/C=JP/ST=Kyoto/L=Kyoto/O=Example/CN=$CN"
openssl x509 -req -days 1024 -in server.csr -signkey server.key -out server.crt
rm server.csr

server.key と server.crt を使って HTTPS サーバを立てます。

ホスト名解決

localhost だけでの開発ならいいが、LAN 内のスマートフォンなどから HTTPS な開発環境にアクセスしようと思うと、IP アドレス指定してもアクセスできない。Chrome の場合、ERR_CONNECTION_CLOSED (This webpage is not available) になる。

どうやらホスト名でアクセスしないとブラウザ側で強制的に接続を切るようで、どうしようもない。

ということで、一旦 LAN 内に DNS サーバを立てて該当コンピュータを名前でひけるようにする必要がある。(mDNS でいけないかと思ったけどダメだった)

node で DNS サーバを書ける実装もある (node-dns (native-dns)) のでこれを使えばとりあえず簡単に書ける。

• https://github.com/cho45/dedns

/etc/hosts 形式を読んで A レコード返すだけのは雑に書いた。

立てた HTTPS サーバと同じマシン上で良いので、port 53 で起動する。sudo が必要。

端末側でもこの DNS サーバを参照する必要がある。

Android では Settings → Wi-Fi → (接続中のネットワーク名を長押し) → Modify network とすすんで、Show advanced options にチェックを入れ、IP settings を Static に変え、DNS 1 にマシンのIP Addressを指定すれば反映される。

またはルータの設定を書き変えて DHCP 経由で通知する DNS サーバを変えてもいいけど、これはこれで面倒。

問題点：first paint がなかなか発生しない

HTML Imports はポリフィルされていない場合ブロックする (Chrome にしかネイティブ実装されてないから Chrome だけ)。インポート先がインポートしている場合再帰的にインポートするので、依存全部インポートが終わるまで表示が完全にブロックし、head内でインポートしていると画面描画が全く走らない。

Chrome の場合 first paint が走るまで現在表示中の内容を消さないので、リロードした場合特に「全く操作はできないのに表示はされている」状態になって気持ちが悪い。

なので、まずはインポートなしの状態ないし、最低限必要なものだけをインポートしてから、ロード画面を表示する。

ローディングプログレスがとれない

link要素のloadイベントでひとつのインポートの完了はわかるが、再帰的な全てのリクエストのプログレスをとることができない。

どうしようもない？ぽいので、intermidate なローディングプログレス表示するしかない。

CSS でアニメーションさせるのが現状では一番マシっぽい。

• http://ultra.zone/loading-animation-generator

コード

		<div class='loading'></div>
		<my-app></my-app>
		<script>
			requestAnimationFrame(function () {
				var link = document.createElement('link');
				link.rel = "import";
				link.href = "src/app.html"; // my-app の定義
				link.addEventListener('load', function () {
					var loading = document.querySelector('.loading');
					loading.parentNode.removeChild(loading);
				});
				document.body.appendChild(link);
			});
		</script>

link rel="import" は作って挿入してもちゃんと動いてくれるのでこれで良い。polyfill もちゃんと動いててうまく動く。

load イベントは再帰的なロードが全部終わってから発火するようになっている。

将来性

HTTP2 化してもカスタムエレメントの初期化処理はなくならないので、大量のカスタムエレメントを使う場合なんらかのローディング表示が必要ではないかという気がする。

appmanifest によるスタンドアロンアプリ化ではコンテナ(ブラウザ)側でそのうちちゃんとローディング出せるようになりそう。

現状

紙 vs コンピュータという点では、結局筆記で書いていくのは自分の場合長くは続かない気がしている。

今のところ8ページぐらい消費したけど、今やっていることに対してはそこそこ良い感じがする。ある程度以上に複雑になると図がないと厳しいけど、コンピュータ上で図を書くのは、書けないことはないけど今のところペンで書くよりも早く書けない。

一方で書いた図を編集させるのが難しいので図の試行錯誤はしにくいのと、字を書く分にはコンピュータ上に書いたほうが早いので、思考過程を最終的にデジタル化したいなら最初っから Inkscape 極めたほうが有益そうではある。

回路図

前回は 5V バッテリーの出力を直接合成しようとしていたが、それだとバッテリーの個体差によって電圧の差が大きく、うまくバランスできないうえに、損失が大きくなるという問題があった。

今回はバッテリー出力それぞれを欲しい出力電圧付近まで DC/DC で昇圧してから合成することにした。これにより、DC/DC で電圧で調整が効き、かなり近くに電圧をあわせられる。昇圧後に電流制限回路とダイオードを入れ、ロードシェアさせている。

FET は、最大で、許容する電位差×最大電流値だけの損失を発生させる。±0.5V 700mA だと 700mW。空冷でもよさそう。ただ、全体の許容電流を超えた電流を流そうとすると損失が激しく増えて熱くなるので危険。

結果

電圧を高めにして、ゆっくり電流を増やしていくと最大28Wぐらいとれた。

問題点

オフィシャルな解決方法

https://github.com/grbl/grbl/wiki/Interfacing-with-Grbl にもFAQ的に書かれている。ここで書かれているのは、planner buffer queue size (設定すると status として出力できる) を見ながら、一定のキューサイズを保つ、という方法である。

しかしこの方法には以下のような問題がある

• planner buffer queue size を status に表示させるのが面倒
  • 毎回 $コマンド送るの？みたいな
• キューサイズを決めるのが難しい
  • 少なすぎるとスムーズに送れず、多すぎると止まるまで時間がかかる
• どっちにしろ入れたキューは消せないため、うまくやらないと止まるまで時間がかかる

Hold & Reset

次に思いつくのは Hold してから Reset するという方法である。Grbl は Hold など一部のコマンドはリアルタイムで処理されるため、キューサイズに影響されない。

つまり、動いているときに Hold させて即時停止させるということは可能。そしてその状態から Reset を行えばキューをクリアできるため、実質的にジョギング相当になる。

しかしこの方法には以下のような問題がある

• Hold -> Reset の遷移が安定しない
  • Reset during cycle エラーがでたりする (位置がずれてる可能性がありますよということ)
• Hold → 実際の Hold までディレイがある場合 (ネットワーク経由でHoldするとか) 停止までの時間が安定しない

ということで使えない。

インターバル方式

ということで別の方法を考えた。これは1つのGcodeあたりの実行時間を一定とし、一定時間ごとにキューイングする方式。

理想ジョギングはステップ単位で進むわけではなく、フィードレートのみに依存しているわけで、それに近い挙動をすることができる。

インターバルは Grbl へ送信してキューに入るまでの時間よりも長い時間をとる必要がある。ネットワーク経由だと少し大きめに設定する。

例えば 0.3sec インターバルでフィードレート800mm/minで送る場合、4mm ずつ送ることになる。

この方法のメリットは

• 一定時間(インターバル)以内に必ず動作が止まる
• 追加の設定が必要ない
• 実装が簡単

デメリットは

• インターバルよりもキューイングに時間がかかった場合スムーズに送れない

ぐらい。

実際のインターフェイス

実際はステップジョギングと可変フィードレートを併用できるのほうが嬉しいため、以下のような挙動にした。

• マウスダウン直後は1ステップ送る
• 終了後1秒間そのままでいるとステップから計算した可変フィードレートで上記インターバル方式のジョギングを行なう

かなり自然なジョギングができるようになって満足

vertex shader

頂点ごとの処理内容。線分だったら始点と終点。頂点の最終的な位置を決定する。ついでに頂点ごとの属性 (attribute) から fragment shader に渡すものをどうするか決めたりする。

最終的に gl_Position にスクリーン座標を代入する。

fragment shader

ある断片ごとの処理内容。線分だったら始点から終点までの各要素を分割した1要素 (線分をレンダリングしてピクセル単位にしたときのピクセル単位)

最終的に gl_FragColor に vec4 型で色情報を代入する。

varying として vertex shader から渡された値は、各断片ごとに値が変更されて渡ってくる。

gl_FragCoord という変数があり、これには実際に処理しようとしているピクセル座標が入ってくる (スクリーン座標系)

gl_FragCoord から元の世界座標系を計算するのは面倒なので、fragment shader で世界座標系が欲しい場合 varying で座標を渡すのがてっとりばやい。

varying variables

varying は vertex shader と fragment shader とを繋ぐものだが、vertex shader でセットした値がそのまま fragment shader に渡るわけではない。fragment shader に渡るときに該当する fragment について計算された値が渡ってくる。

https://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/varying.php

コレットナットを軸からはずす

普通に緩めて外すだけ

ナットからコレットを外す

コレットをちょっと押してみると、ナットの位置によって傾むくほうと傾かないがあることがわかる。

傾むくほうを下にして、そのまま下に少し強めに押すと外れる

ナットにコレットをつける

ナットの内側をよくみると、コレットの溝にはまるようにリングがついていることがわかる。そしてそのリングが一方が深く、一方が浅いようになっている (偏心している)

なので、深いほうを先に入れ、浅いほうに向けてコレットを押しこむとつけられる。

ナットを軸につける

普通に締めるだけ

いちいちナットにコレット脱着するのが面倒だ!!

ナットだけ追加で買って、1コレット1ナットをセットにしてしまうのが早い。これなら、緩めて別のナットをつけるだけですむ。