PropGit
commented
9 years ago @2fast2fourier - First, I'm officially recognizing that you've improved the processing and visual response of the Receive Pane very much. It now delivers a very snappy response to fast-received data; nearly as fast and smooth as the BSE! Fantastic!
However, the original problem shown in the first video still exists, although it seems to be a little better than before. In addition, if you take the code from the original video, let it run, scroll all the way up, then grab the scroll bar thumb and slowly scroll down, the problem alluded to in the second video is exhibited by the display quickly switching from showing lines in the very early 100's to lines in the late 200's. For most data (ie: not text showing the actual line numbers) this would go unnoticed and would trick the user into thinking they haven't missed anything (100+ lines, in this case).
I'm reopening this issue but I'm bumping it's priority down to address other items on the list first and to leave time for you to think about other possible solutions for discussion in the near future. The ultimate goal, of course, is to get it to process, display, and scroll data in a similar smooth fashion as is exhibited by the BSE's Debug Terminal.
The Receive Pane scrolls awkwardly when there's many lines of text to scroll back to in history. This is best demonstrated by this video example and another video that shows a problem at the opposite end of the history.
Note: In addition to the strange looking behavior where the first text appears at the bottom of the display (which I'm not calling a bug by itself) the other side effect inherit in the solution employed causes the scroll thumb to stay staticly sized (and pushed to the bottom of the scroll bar). Without the scroll bar thumb resizing, there's no quick-glance visual indication of the size of the Receive Pane's history.
I think Blaine mentioned that avoiding the Chrome scroll bar was problematic, but I see solutions that seem to work great, like jScrollPane, jQuery slimScroll, Control.ScrollBar, and the one that may be the most most promising, Tiny Scrollbar where the size and thumb can be set manually (maybe others do that also). All of these examples even catch non-focused mouse over + scroll wheel activity and non-focused mouse over + shift + scroll wheel (which is a big plus for easy vertical and horizontal scrolling, respectively).
Similar to what I've said before, I suggest that the Receive Pane display be a logical view port into the internal line buffer- this view port's content is delivered to it dynamically (the Receive Pane never actually has more content than what is visible; unless a little extra helps with scrolling in some way) and the custom scroll bar's thumb size be adjusted by code according to the size of the internal line buffer, and of course the thumb position is synchronized with the view and the view is synchronized with the thumb. Also, the reclaimed buffer area (for head-meets-tail moments) be limited to a single-line at a time, to improve the visual experience for the user so that the display is not so jumpy when the circular buffer is full. This assumes the standard focus, keyboard, mouse controls are active for this scrolling region. I can elaborate more if needed.