Renders the HTML from the Markdown source in a separate thread, fixin… #73
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…g lag in the text window while typing, specially on large documents. Adds a 200 ms delay between the text change event and the start of the rendering process to avoid triggering rendering requests in bursts while typing. Fixes issue jamiemcg#13.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What changes:
UpdateThreadclass that inherits fromthreading.Threadto run the conversion between the markdown source into the HTML for the live preview in a separate thread. An instance of this class is owned by the main window and is started when the window shows. The update thread runs in parallel for the duration of the program, sleeping while there's no rendering requests.update_live_preview()method now sets up a GLib timer that notifies the update thread that a new update to the live preview is needed. If this method is called again before the timer has fired, it resets the timer, effectively cancelling the previous update request. The end result is that while the user is typing in rapid succession, updates to the live preview are postponed, avoiding rendering in bursts. The timer delay is set to 200 ms, a sensible value according to my tests.It is worth mentioning that, unlike the markdown to HTML rendering, the actual update to GTK widgets (i.e. setting the HTML in the Webkit widget and recalculating the scrolling) are enqueued as low priority tasks in the main thread, since GTK is not thread safe (See Threads/Concurrency with Python and the GNOME Platform).
These changes mostly fix Issue #13 (see extreme cases below).
Tests
I tested these changes in Arch Linux (python-gobject 3.22). I compared the behavior of Remarkable with and without these changes, with small files (~ 1000 characters, a few paragraphs), medium files (
15,000 characters, about the length of a blog post), large files (100,000 characters, about the length of a small book like The Little Prince) and very large files (~ 4M characters, the size of the Bible). For small and medium files, the only perceived change is that the delay rendering logic doesn't update the live preview as often as before. Without the changes, large files couldn't be edited with Remarkable with the live preview on, as every time you typed a character the editor would become unresponsive for about a second or two. With the changes they are editable with the live preview on with no perceived issues.Now, very large files (I used the King James Bible) are still largely unable to be handled with the live preview on. The responsiveness is greatly improved in those cases, though. We need more testing for these extreme cases to zero in the bottlenecks.