GIFをparseするjsなライブラリ(2)

 プログラム
 公開日:2017年2月28日

 先日、
GIFをparseするjsなライブラリを作ったりしましたが、
parseするのにそれなりな時間が掛かったりするので、
progress表示とかがうまくやれない感じ。
そんなわけで、
web worker を使って別スレッドで動かすことで、
非同期でやれるように作り直してみることしました。

 ところで、
web worker を使うには、

とかやって、
別なソースファイルからworkerを作るのが普通だと思います。

 workerを使うのは久しぶりだったので、
あらためて使い方なぞをネットで調べていたら、
ここここに書いてあるような
inline worker という手法があることを知りました。
実質的に以下のようなことが出来てしまいます。

個人的にこんな発想はありませんでした(^_^;)
なるほど分かりやすい感じになりますね。
ソースファイルを分けなくても行けるのが便利です!

 どうやって実現しているのかと思ったら、
関数のコード ⇒ 文字列化 ⇒ blob ⇒ ObjectURL
とかやってました。

なるほど納得!
うまいこと考えましたね。
ソースコードのイメージを作って、
ブラウザ内のメモリに置いたのをURLで参照という感じかな。

 なお、
上記のページでは、
“text/javascript”なMIMEでblobを作っていますが、
“application/javascript”の方が新しい指定なようです。
どっちでも動くと思いますが。

 同じソースファイルに書けるとは言っても、
workerとして渡す関数は別スレッドで動くので、
必要なコードが完結するようにしないといけません。
主スレッド側に書いた関数とか呼べないので要注意です。
1つのソースファイルに書けてしまうので、
いかにも呼べそうに見えるのが罠です(^_^;)
また、こちらによると、
inline-worker内でimportScripts()する場合は、
絶対URLで指定する必要があります。
相対パスだと例外が起きます。
inline-worker自体はblobスキームで生成されるので、
cross-domainな制約を受けるためだそうです。
相対パスな指定だと blob:扱いになってしまうっぽい。

 ちなみに、
デバッグしていて気付いたのですが、
worker側からErrorオブジェクを送信したら、
Uncaught DOMException: Failed to execute ‘postMessage’ on ‘DedicatedWorkerGlobalScope’: An object could not be cloned.
こんな感じのエラーが起きました。
調べてみても理由がよく分かりませんでしたが、
Errorオブジェクトにはstackトレースが含まれてるためだと思います。
スレッド固有な情報を別なスレッドで処理したらマズイことになりそうだし。

とか思ったんですが、
{message: error.message, stack:error.stack}
こんな感じのオブジェクトを作って返すと例外は起きませんでした。
ということで例外起きる理由はやっぱよく分からない・・・。
しょうがないので文字列化して送信しました(^_^;)

 ということで、
inline worker な手法を取り入れて、
ライブラリを作り直しました。
ここで書いた具体例のコードも以下のように変わります。

 拙作のライブラリを使って、
作ってみたツールはこちらから試せます。
ライブラリのダウンロードも行えます。

タグ:

コメント投稿