I'm noticing extremely fast scrolling in the script editor, file type list and preferences window's left-side list when using a Precision Touchpad. The file display and folder tree work fine.
I did some testing (using ahk and spy++) and found that these specific controls seem to ignore the scroll delta. Even if I send a tiny scroll signal (e.g., delta=1), the editor moves a full line.
It looks like the control treats every single touchpad event as a full scroll step, instead of accumulating the small values for smooth scrolling.
Directory Opus 13.20.6 (Beta) Build 9414 x64
OS 10.0 (B:26200 P:2 T:1) SP 0.0
I think it's a problem system-wide. The drivers for precision scrolling in Windows have been broken for a long time.
There's no way to make it work all the time. You either get extremely slow or extremely fast scrolling in one place or another. Last I checked, it also affected File Explorer and other software (one way or the other) when a "precision trackpad" type device was installed.
Scrolling in Windows only works properly with regular mousewheels.
I am not sure if this is purely a driver issue, as my testing suggests the system is actually sending valid input.
I used Spy++ to monitor WM_MOUSEWHEEL messages on two different controls: BrainchildEditControl321 (Script Editor) and dopus.filedisplay (File Display).
Both controls receive the same stream of high-frequency messages with small deltas (e.g., zDelta=1) when using the touchpad. This indicates Windows is correctly converting touchpad gestures into standard high-resolution wheel events.
The Difference:
dopus.filedisplay handles these small deltas correctly by scrolling smoothly (pixel-by-pixel or small increments).
BrainchildEditControl321 seems to ignore the zDelta magnitude entirely, treating every single message as a full scroll step (based only on the sign).
I verified this behavior using an AHK script: sending a single WM_MOUSEWHEEL message with delta=1 to the Script Editor causes it to jump a full step (3 lines), whereas it should barely move.
According to Microsoft's documentation on WHEEL_DELTA:
To use this feature, you can either add the incoming delta values until WHEEL_DELTA is reached... or scroll partial lines in response to the more frequent messages.
Since the File Display works perfectly with the exact same input stream, this looks like a specific implementation issue in the Script Editor (and other affected lists) rather than a system-wide bug .
Not all windows/controls support high-resolution scrolling. (In a lot of cases, there's no reason to, as they can only scroll whole lines at a time anyway.)
When you scroll in a control which doesn't support high-resolution scrolling, the mouse/touchpad drivers are supposed to synthesize a normal scroll wheel message.
And while they do usually do that, the problem is they tend to do it in a way that has completely different scroll speeds to the high-resolution messages.
This results in people with those touchpads increasing the scroll amount in Windows (up from the normal 3 lines per wheel click to something much larger) to compensate for slow scrolling in one type of window, but with the side effect that the other type scrolls far too fast.
The post I linked to has examples of this problem in Windows itself. It's not just an Opus issue.
.