ノートPCのタッチパッドにおけるホイール処理

ノートPCについているキーボード下のタッチパッドにおけるマウスホイール処理についてメモしておきたいと思います。
実は難物なんですこれ・・・。

イベント内容

パッドを使ったホイールスクロールの場合は、マウスによるホイールスクロールとは異なり、特殊な数値のイベントが飛んでくるので、処理やインターフェイスの根本的な見直しが必要になります。

・マウスによるホイール
MouseWheel(WheelDelta:-120) 230ms
MouseWheel(WheelDelta:-120) 102ms
MouseWheel(WheelDelta:-120) 85ms
MouseWheel(WheelDelta:-120) 123ms

・ノートPCのパッドによるホイール
MouseWheel(WheelDelta:-14) 12ms
MouseWheel(WheelDelta:-10) 10ms
MouseWheel(WheelDelta:-8) 13ms
MouseWheel(WheelDelta:-9) 8ms
・・・

マウスのホイールでは上下に1回2回といったグリッド間隔による回数によってイベントが発生していますが、パッドの場合はもっと細かい単位(ピクセル)の連続したイベントが飛んできます。
また、デバイスの設定によって離した後のイージングも発生します。
(イージングを判定するコードは見つけられませんでした。判別出来るか不明)


と、こんな違いがありますので、対応処理が必要です。
まじめに対応すると場合は、プログラム的(イベント処理)な対応と、GUI(グラフィックインターフェイス)の両方が必要になります。

対応しないとどうなるの

対応していないからと言って、そこまで深刻なバグが発生するわけではありません。
よくある実害が、パッドでスクロールさせると超高速でスクロールするぐらいです。
上記の通り、スクロールイベントが細切れで大量に飛んでくるのが原因です。

対応 - イベント処理

パッドによるイベントは、間隔が非常に狭いため、Wheel値をポーリング処理(ゲームの1frame単位で値を取得して処理)で取得している場合はかならず抜けオチが発生します。
抜けオチが発生すると、スクロールする移動量が一定で無くなります。(早くスクロールしたのに遅かったり、逆になったり)
なので、イベントから値を取得し、WheelDelta値は加算、累積しておく必要があります。

対応 - GUI(グラフィックインターフェイス

大変なのがこれ(GUI)です。
デザインそのものから見直す場合もありますので、昔の作品をプログラムを弄って対応…と単純にはいかないでしょう。


簡潔に言ってしまえば、GUIピクセル単位のスクロールに対応させることが対応処理になります。
ということとは必然的に、「1回のスクロールでページが切り替わる」といった処理はこれに反します。
例えば、スクロールでページが1進むようなのがこれに該当します。
…厳しいですね。
「一定ピクセル数のスクロールになったらページを進ませる」というのも手ですが、引っ張り動作(スクロールさせた量だけ移動するが一定未満だと元の位置に戻る)を入れないと大変不親切なインターフェイスになってしまいます。
また、イージング処理イベントも飛んでくるので、引っ張り動作が正常に出来る保証もありません…。


というわけで、ピクセル単位のスムーズなスクロールを前提に作り直さないとどうにもならないなー、と個人的には思っています。
この方式は「見えている部分のリソースだけ処理して処理とメモリをコンパクトに」というのが大変やりにくいので、リッチな処理(重い)になる傾向が強いですし、全てを対応とかでなく、天秤にかけて取捨選択が現実ラインではないかと思います。
ページ切り替えぐらいで悩むならボタンでもいいかなってね。
かしこ