refresh only if event queue is empty

[rricharz]

The problem with the slow down of keyboard entries on slower computers has to do with too many refresh events that have been pushed to the event queue. This fix will only refresh if the event queue is empty, e.g. no events such as keyboard events there anymore. If there are any other events there, they will be handled before the next refresh is executed.

The fix allows to run vt100 on slower computers such as the Raspberry Pi. I have checked it on a Raspberry Pi 5, with and without vnc.

No keys should be lost anymore and vt100 should not go into a state anymore in which it is extremely slow and not responsive.

[larsbrinkhoff]

Thank you for this. However, I believe (I haven't actually checked) that not posting a new refresh event will cause no future events to happen. I think the right thing to do is to exit in the same place the fields logic does.

[rricharz]

Lars, you are right. Not posting a refresh event will cause no future events to happen. But thats not exactly what my proposed fix does. What it does is just not to execute the refresh itself if the event queue is not empty. It still posts of course the next refresh event. This means that one or several refreshs will not happen, allowing the event queue to execute all other pending events. The refresh rate is reduced dynamically while other keys are pending.

By the way, under certain rare circumstances a keyboard input can still be lost. I think this is because of the way you have implemented the keyboard input. If the key up event happens before the next scan, the key will be lost. I assume this happens if the key down and key up events happen both during a single refresh. Somehow the key down event needs to be properly memorized until scan has found that the key has been pressed. I think this can also happen with a lower probability on faster systems.

Also I have seen it screwing up once or twice during a vi. I think this probably means that also characters from SimH can be lost under certain circumstances, putting vi in a strange mode.

It‘s fine with me not to accept this pull request. You have certainly more insight into the program than I do. But running the program on a slow system is certainly a stress test for the proper handling of keyboard and character inputs. It should still work properly, but with a too slow refresh rate.

[larsbrinkhoff]

Sorry, I see you are correct. I misread the diff. I'll happily merge this, but I'll just make a minor edit to the commit.