macOS + Node server: Latency with high polling rate devices
まだ誰も着手していません。
評価
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 初心者へのやさしさ
- 20/100
- issue の種類
- バグ
- 明瞭さ
- 説明が足りない
- 活発さ
- 停滞
- 技術スタック
- cpp, macos, node.js
調査の方向性
bindings/Node/libpointing/pointing/pointing.cc から始め、commit 11bb753de457cfce719e1edbe4509739f557cbbc における macOS のイベント処理の変更を調査します。125Hz を超える頻度でポーリングするデバイスを使って macOS 上で Node binding を再現し、その後、HID callback のレイテンシと JavaScript の応答性のトレードオフを調査します。コールバックがアプリケーションをフリーズさせずに速やかに到着すれば完了です。
索引モデルが issue の本文から書いたものです。
説明
With libpointing's new nodejs binding on macOS, devices with high polling rate (i.e. > 125Hz) "lag": the js client receives the reports much later than it should, creating a very high latency.
After some digging, it seems to be related to the cohabitation of the Cocoa's event loop with Node's main loop. Long story short: Node does not process all macOS events in its main loop and therefore HID callbacks are never called. libpointing solves this problem by processing macOS events every tick for Xms (see https://github.com/INRIA/libpointing/blob/master/bindings/Node/libpointing/pointing/pointing.cc#L30, the time given to macOS event processing was recently reduced in 11bb753de457cfce719e1edbe4509739f557cbbc). This solution is basically a trade-off: if we give more time to process macOS events, then JS events are not treated as quickly and the app freezes, but if we prioritize the JS event loop, then the HID callbacks are not called as quickly. I experimented with different values to find a better trade-off, but nothing seemed ideal. The current value seems fine for devices with low poll rates (<125Hz).
Related StackOverflow issue (no answer): https://stackoverflow.com/questions/33599653/c-callbacks-are-not-called-for-node-bindings
It seems that this problem could also be solved from the js code, by re-writing node's main loop to process macOS events, but it is pretty involved and require the use of platform dependent APIs in JS: https://github.com/TooTallNate/NodObjC/issues/2
Tested on macOS Catalina.
- 主要言語
- C++
- スター
- 54
- フォーク
- 14
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
INRIA/libpointing のほかの issue
-
難易度 3/5 1〜2日 初心者へのやさしさ 42/100
INRIA/libpointing#40 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 38/100
INRIA/libpointing#26 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 35/100
INRIA/libpointing#22 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 28/100
INRIA/libpointing#17 · コメント 1 件 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 20/100
INRIA/libpointing#10 ·
INRIA/libpointing の issue をすべて見る
似ている issue
-
`IO.FS.realPath` reports every failure as `noFileOrDirectory` instead of classifying by `errno`オープンbug
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
leanprover/lean4#15683 ·
メンテナーはふだん 1 日以内に返信
-
llvm.memcpy with destination align but no source align asserts "Missed Source alignment!"対応中かも @pvelesko が今日担当しました。 オープン
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
KhronosGroup/SPIRV-LLVM-Translator#4093 ·
メンテナーはふだん 2 日以内に返信
-
難易度 2/5 1〜3時間 初心者へのやさしさ 66/100
メンテナーはふだん 1 日以内に返信
-
SIMQ silently truncates multi-query batch search to the first query対応中かも @LHT129 が今日担当しました。 オープンkind/bug module/index needs-triage
難易度 2/5 1〜3時間 初心者へのやさしさ 72/100
antgroup/vsag#3080 · コメント 1 件 ·
メンテナーはふだん 1 日以内に返信
-
難易度 2/5 半日 初心者へのやさしさ 68/100
メンテナーはふだん 1 日以内に返信