Fix/windows simulator arrow key#910
Open
siudesu wants to merge 1 commit intocoronalabs:masterfrom
Open
Conversation
Author
|
Whoops. meant to include only 138ec32 |
Contributor
Make sure you keep the copy on your local! Then, |
|
|
… split button When a Lua key listener does not return true, unhandled WM_KEYDOWN messages fall through to DefWindowProc. Win32 keyboard navigation routes VK_UP and VK_DOWN to a split button control in the simulator, which triggers a pair of synchronous BCM_SETDROPDOWNSTATE messages (True then immediately False) on every keypress. This synchronous round-trip into the button control's window procedure disrupts update/render loop timing. VK_LEFT/VK_RIGHT do not exhibit this behavior. Fix: mark VK_UP and VK_DOWN as handled in the unhandled-key else-branch so they never reach DefWindowProc. Verified via Spy++ which confirmed BCM_SETDROPDOWNSTATE firing on every VK_UP/VK_DOWN keypress and its absence on VK_LEFT/VK_RIGHT. <000229> 000408EA P WM_PAINT hdc:00000000 <000230> 000408EA P message:0x0500 [User-defined:WM_USER+256] wParam:00000006 lParam:00000000 <000231> 000408EA P WM_KEYDOWN nVirtKey:VK_DOWN cRepeat:1 ScanCode:50 fExtended:1 fAltDown:0 fRepeat:0 fUp:0 <000232> 000408EA S BCM_SETDROPDOWNSTATE fDropDown:True <000233> 000408EA R BCM_SETDROPDOWNSTATE fSucceeded:False <000234> 000408EA S BCM_SETDROPDOWNSTATE fDropDown:False <000235> 000408EA R BCM_SETDROPDOWNSTATE fSucceeded:False <000236> 000408EA P WM_PAINT hdc:00000000
siudesu
force-pushed
the
fix/windows-simulator-arrow-key
branch
from
138ec32 to
25fb8ad
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This is a related to #405 (Simulator performance fix: treat repeated keys as handled)
Summary
On the Windows Simulator, pressing the Up or Down arrow keys causes a latency spike, noticeable visually when pressed repeatedly.
Root cause
When a Lua key listener does not return true, the WM_KEYDOWN message is left unhandled and falls through to DefWindowProc. Win32 keyboard navigation routes VK_UP and VK_DOWN to a split button control present in the simulator UI, triggering a pair of synchronous BCM_SETDROPDOWNSTATE messages (set True, immediately set False) on every keypress. This synchronous round-trip into the button control's window procedure disrupts the update/render loop's timing. VK_LEFT/VK_RIGHT do not trigger this behavior.
This was confirmed via MS Spy++ message logging on the render surface window:
Fix
In the else branch of the key event handler (i.e. when Lua did not handle the key), VK_UP and VK_DOWN are now explicitly marked as handled so they never reach DefWindowProc. This is consistent with how the back key is already handled in the same branch.
Testing