Windows simulator: "up" and "down" key events result in significant FPS drops
I've run into an interesting bug on Windows simulator and I've attached a sample project that demonstrates the issue clearly.
In the sample project, if you press "s" or "w", the circle in the middle of the screen moves up or down, as expected. However, while you're holding down "s" or "w", if you then push and hold down either "up" or "down" arrow key, then the FPS will get halved.
This behaviour is interesting because it only occurs IF you press down "up" or "down" while the circle is already moving. If you start by holding down "up" or "down" and only afterwards start moving the circle by pressing "s" or "w", then there's no FPS drop.
This issue seems to only persist on the simulator. Once you build for Windows, the issue is no longer present. I'm not sure if this issue affects MacOS as well.
Sample project: keyEvent issue.zip
I discovered this was happening to me and I've been driving myself crazy the last few days hunting for it.
I noticed if I just tapped the keys a lot, nothing seemed to go amiss, so I tried triggering the repeat logic here https://github.com/coronalabs/corona/blob/master/platform/windows/Corona.Native.Library.Win32/Rtt/Rtt_WinInputDeviceManager.cpp#L966 and following it. It does quite a lot of fallback logic.
If you add the "key was handled" logic inside of it, however, suddenly the slowdown is gone!
I believe this is sound; only the backspace logic might be affected, but it should be handled by the WM_KEYUP case (for that matter, we shouldn't really need the repeat case here, no?).
It looked to be like the up and down keys were getting sent to the back of map used to look up their names. This is the only real guess I have for why they trigger this major slowdown but no other key seems to. If there's a better answer I'd love to know! :smiley:
I don't quite have the test case to pursue this, but I suspect something might be going on with the similarly noisy mouse moves: https://github.com/coronalabs/corona/blob/master/platform/windows/Corona.Native.Library.Win32/Rtt/Rtt_WinInputDeviceManager.cpp#L545. A few people have complained about this being a major performance drag.
Should be fixed by referred PR