Paste Text Very Slow & Delay Between Keys Only Seems to Work at 50 and Above

[rmschooley]

Disclaimer

• I have read and understood the disclaimer.

Application version

0.4.8

System version

0.2.5

Device model

JetKVM

Extension model

None

Remote device Hardware

No response

Remote device OS

No response

Bug description

"Paste Text" seems to be working, but it is woefully slow. By default, "Delay Between Keys" is set to 100. I'm not exactly sure what this means -- perhaps number of milliseconds between a key press and a key release event?

I can change "Delay Between Keys" to 50 and the paste seems to work about twice as fast. If I enter something less than 50 for "Delay Between Keys", the code seems to act as if it is set to 100. I just noticed that the arrow buttons in the edit box limit this value to 50.

Although I guess I can see a reason for having some amount of delay between key press/release events, is there any reason why it cannot be significantly less than 50? Most decent typists can type much faster than the rate of the paste when "Delay Between Keys" is set to 50.

[rcv11x]

I can confirm that when you paste text now, it is very slow.

[IDisposable]

The problem is multifold... one is that the between-key delete is too long when we're playing the macro from the paste screen to the keyboard. Additionally the emission of all the keystrokes at once means that for very large pastes, the actual message sent from the client/browser (which is sent via RPC) is the entire paste as-if it was a keyboard macro. This means that the actual network call can be quite large before the client even starts to see the key-paste and then it plays it back at the rate determined by the .delay in the macro steps (which currently defaults to 100). But the biggest limit is that we're "playing" the macro device-side by faking pressing the requisite key, waiting a delay, releasing the key, and the sending the key status back to the client so there's just a ton of messages going back. I bet if we only send the "final" key status state back (device side having played out the macro) it will move along much quicker.

[IDisposable]

I've put in a PR that somewhat address most of the issues #829