High mouse report rate / polling rate causes severe lag / slow down

[Codex-]

Related: #521

Creating a new issue regarding this as I can recreate this 100% of the time.

I spent a few hours trying to work out why my PC couldn't handle running desmume, but it turns out it was because of this issue.

My specs:
CPU: AMD Ryzen 5900x
GPU: Nvidia 3070ti
Memory: 32gb
OS: Windows 11 10.0.22631 Build 22631

Can recreate this yourself by simply adjusting the polling rate of your mouse to 1000 or something high and then click + dragging for input (i.e. running in Phantom Hourglass)

Please see:

output.webm

Console:

DeSmuME 0.9.14 git#25cbcd2 x64-JIT SSE2
- compiled: Sep  3 2023 10:07:49

DirectX Input:
   - gamecontrol successfully inited: Bluetooth XINPUT-compatible input device
Microphone successfully inited.
DeSmuME 0.9.14 git#25cbcd2 x64-JIT SSE2
Attempting change to 3d core to: SoftRasterizer
SoftRasterizer: Running using 24 additional threads. (Multithreading enabled.)

ROM game code: AZEE
ROM crc: 8B431C41
ROM serial: NTR-AZEE-USA
ROM chipID: 00003FC2
ROM internal name: ZELDA_DS:PH
ROM developer: Nintendo

Slot1 auto-selected device type: Retail MC+ROM
Slot2 auto-selected device type: None (0xFF)
BackupDevice: size = 4 Mbit
CPU mode: JIT
JIT: max block size 100 instruction(s)
Already decrypted.
WIFI: MAC Address = 00:09:BF:12:34:56
WIFI: Emulation level is OFF.
Loading [snip] was successful
Emulation unpaused
snddx: emergency cleared sound buffer. (-11028, 0, 11270)

I also tested the same issue against older nightly releases (2022) and against the last two releases, finding the same behaviour. Also worth noting I experience the same behaviour with stock settings on a fresh install / run.

the mouse input needs to be throttled / denounced, here, perhaps?

[zeromus]

We're not going to change how mouse input is polled because you send more mouse input than windows can handle. We can't test this without the relativity studies lab where you alter the time-space continuum to poll input faster than electrons can jump shells. Try making a build without the call to SetCapture() perhaps and see if that fixes it. I guess that's a bit odd.

[Codex-]

We're not going to change how mouse input is polled because you send more mouse input than windows can handle.

It's not a case of whether windows can or cannot handle the inputs, it's more a matter that thousands of inputs are captured, many more times than what is polled and collected by a DS itself so you could argue trying to handle every pointer event is less accurate

Many mice and the software associated with them have specified polling of 1000 for over a decade now, this is nothing new.

We can't test this without the relativity studies lab where you alter the time-space continuum to poll input faster than electrons can jump shells.

Not sure what response you want to this? Seems unnecessary, I'm trying to provide information that would be conducive to finding a reasonable solution, not to provoke you.

Try making a build without the call to SetCapture() perhaps and see if that fixes it. I guess that's a bit odd.

Would it make sense for the pointer capturing on the window to be relatively bound to the framerate or perhaps limited by what the DS can capture itself?

[zeromus]

no. windows sends us the events. we handle them. the difference between handling them and not handling them is negligable if it's fast. It's fast. The only thing I can see in the handling that could be slow is win32 SetCapture(). Moreover the input needs to be limited by what your operating system can handle (both in terms of mouse speed and monitor hz) because you may be doodling in a lua script on a paused game. It's got nothing to do with the NDS itself. You may also be running an NDS game in fast forward at 1000fps.

It's also possible something we've done to wrestle with making tablets more compatible causes your operating system to choke due to slow tablet APIs or glitchy drivers. Not many programs are screwing around with the tablet APIs. In that case whether or not we handle messages is moot since windows is clogged up just sending them to us. You may try removing GlobalAddAtom() and SetProp() on the tablet-related code in main.cpp. Maybe also delete WM_POINTER* message handling as well.

You can also try changing config > display method because your operating system may choke sending messages to windows being conducted in a certain idiosyncratic way, and in windows every window is conducted in one idiosyncratic way or another since it requires secret homebrewed arcane rituals to do any damn little thing.