Scroll is getting stuck #36
No Assignees
jabber.developer2
jabber.developer2
Notifications
Due Date
Dependencies
No dependencies set.
Reference: devs/cproof#36
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Current Behavior
When the window is scrolled up (
[SCROLLED]state) and new message appears from either side, scrolling down might cause getting stuck in the middle of the conversation. The state will switch from[SCROLLED], yet only new message and middle (arbitrary stuck point) of the conversation is show.Deep Dive
The actual issue is that CProof tries to fetch the history from the wrong range of time.
Data Storage
Long-term storage of the messages, including full conversational history, is stored in the SQLite database.
CProof keeps currently displayed messages in an internal buffer. The messages in the buffer are the ones that are supposed to be displayed. Buffer also contains some display meta-data details, such as message visual location (line numbers) size in lines. Actual location of each character, scrolling and other UI details are stored in and handled by the NCurses.
NCurses' window size (
PAD_SIZE) is 10.000 lines. Once exceeded, any text that was written there would disappear (causing window to be stuck). To avoid this issue, we track line sizes in the NCurses' window buffer and delete messages from the other side of the buffer.Events
Once a new message appears (sent or received), it is immediately appended to the internal buffer.
Once user presses
page_down, to determine which messages are needed to be fetched, CProof utilizes the latest message's timestamp as a starting point in the DB request. Since new message's timestamp is nearly current date, no other messages are found from the DB to fetch. It causes CProof to assume that the end of DB is reached.Potential solutions
1
Avoid displaying new messages if scrolled past the buffer size. Just add them to the DB to be scrolled into eventually. It would preserve message ordering.
Questions: how to determine if scrolled past buffer size?
Downsides: slight complexity and chances of bugs causing messages to not appear.
2
Get rid of a buffer cleanups: add metadata to avoid displaying messages if past the NCurses' size.
Downsides:
Solution Log
Currently, buffer cleanup was improved, masking the issue by PR #37.
Prior to the change, the buffer kept up to
MAX_BUFFER_SIZE=200messages, even though they might take much less than 10k lines. Since line tracking was introducing earlier, it allowed to remove buffer size limitation and scale it based on the amount of lines.However, it does not fix the underlying issue with the message cleanup causing getting stuck, but 10k lines of actual buffer will significantly increase responsiveness of the application and reduce occurrences of message deletion, therefore masking the issue.
Steps to Reproduce
Resolved by #45 and #37