SSH Terminal Emulator: Release 5 Live

Release 5 is now live in the store! Please update and check it out!

2 Responses to “SSH Terminal Emulator: Release 5 Live”

  1. mitch

    Great work! Love the fullscreen mode, and vim is much more usable now that the arrow keys work. A couple things though: Home and End keys seem to work well in the shell (they go to the beginning and end of the line as they should), but in vim, they dont seem to have much of an effect. They push the cursor forward one position, but thats it. Same with page up and page down keys. While scrolling works muuuuch better than it did, it takes a while for the app to draw the screen when scrolling, so it isnt very fluid when moving around in a file.

    It still seems to be thrashing the CPU more than i think should be necessary. I tried ‘ls -la’ in my home directory, which has several hundred items in it, and task manager showed it peaking at about 27% CPU and it took the better part of a minute to display all of the results. By means of comparison, my android phone ssh client can do the same in a fraction of a second. It is hard for me to tell whether this is related to communication performance or drawing to the terminal, so i suppose it could be either.

    I am also getting some strange behavior and crashes from time to time every once in a while it will hang, and when i try to disconnect using the slider, the app crashes. It sometimes happens when the terminal is busy and sometimes when im in vim.

    I hope these aren’t too disheartening. I really think you are on the right track, and hope you keep it up. A couple fixes to performance and stability and I think you will be sitting pretty. Keep up the good work!

    Reply
    • admin

      I’m not sure what the deal is with vim’s home/end/pgup/pgdwn keys not working. I assume it has something to do with VIM’s binding of keys. Perhaps editing .vimrc to alias those key inputs to commands would work? I’m going to do some research on this and perhaps update the User Manual with some info. The thing is I’m sending standard ANSI keyboard commands, so I assume it’s just vim being weird.

      I also looked a bit deeper into the CPU thrashing, and what’s been happening is that since the whole network stack is async, and awaits completion of each step before getting more characters, and since await will sometimes yield the task, it will usually draw the screen between each step. The drawing of the screen is synchronous, so whatever has to be drawn on the screen is drawn before the task yields. Sometimes this is a few characters or a line or two, sometimes this is the whole screen. This means that the network stack has to wait each time the screen is drawn, which is happening pretty often since the whole stack is async. I’ve implemented an interim solution which slows down the drawing of the screen if the network traffic is too high. Doing an ls -la in /usr/bin on a standard unix machine completed in a bit over a second and a half, with about 15 percent cpu usage peak. I tried speeding this up with a run-style drawing technique, where runs of characters with the same style are drawn all at once, but it’s not going any faster, and is using more CPU. Perhaps my implementation is crap, so I’ve kept that code just in case I find a tweak to make it faster.

      I’m looking into crashes and hangs caused by streams getting closed without an enclosing try/catch to keep the app from hanging. I’ve gotten one of the major sources so far, but this stuff is kind of hard to reproduce/test. I’ve gotten the same problem with the disconnect slider, but once again, it’s a bit hard to connect without being able to reproduce it. It happens very infrequently for me.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

     

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>