パス描画の高速化でひとまず解決
パスを書き終わったあとそれが下のキャンバスに落ち下のキャンバスの再描画が走る
- これがUIスレッドをブロックする
- そのため立て続けにパスを描こうとすると不都合がある。
- しかしパスは字を書くなど立て続けに使うものだ。
パスの描画を1ストロークごとに下に落とすのをやめて、ツールの切り替えなどの別のことをするタイミングまで遅らせる これが一人で使うなら正解だと思う ただしリモート共有ホワイトボードとしては伝達の遅延が増えて微妙
2019/6の議論 OffscreanCanvas
- iPadのChromeはバージョン74だった
- 69から入ったOffscreanCanvasを使えばCanvasの更新をUIスレッドの外でできる
もしくは、パスの描画を1ストロークごとに下に落とすのをやめて、 ツールの切り替えなどの別のことをするタイミングまで遅らせるか。 でもなぁ、これ本質的な解決にはならないよなぁ。 根本的な問題はPaper.jsによるCanvasの更新が分割不能な巨大な処理であることなので…。 素朴にループで描画してた js
for (var i = 0, l = children.length; i < l; i++) {
children[i].draw(ctx, param);
}https://github.com/paperjs/paper.js/blob/767ce043bac216eb8a16c817c1d97046d0e01307/src/item/Project.js#L880 このループとそのあとの部分を個別のコールバックに刻んでrequestAnimationFrameしたらいいのかなぁ？？？
OffscreenCanvasについて調べてみたけど、Chrome以外のサポートを当面諦めれば キャンバスをOffscreenに移動するだけでレンダリングが操作をブロックする問題は解決できそうな気配 →iPadのChromeは中身がSafariなので肝心のiPadでの使用ができなくなる、ダメ