Preview jumping

Vince's Avatar

Vince

05 May, 2018 11:30 PM

Since we've dealt with jumping in the editor, it's only right that we also have to deal with jumping in preview. Using Beta 4.4 on OS X 10.12.6.

Periodically (every 10-15 seconds), the Preview is "jumping", i.e. moving up off-screen and immediately back down. I have not being able to pin down a trigger, and the document I'm working in right now is pretty small (less than one screen). I was able to catch it in a screen recording. I've slowed it down quite a bit so you can see it, and I reduced it to 540p so the file size would be manageable. Let me know what else you need.

  1. Support Staff 1 Posted by Fletcher on 06 May, 2018 02:46 AM

    Fletcher's Avatar

    It looks like the jump happens after you type a space and then t (thereby disabling the "don't update preview when typing a space" function), but the preview update must have already been triggered because it doesn't include the t in the preview, meaning the last character it saw was the space.

    When I compare the latest release to the latest beta, the beta seems more responsive (the preview updates more frequently).

    In fact, when typing gibberish, which results in a lot of misspellings to be flagged, it is much faster. Which must be because I was able to revert to the default spell checking behavior with some recent changes.

    I'll have to see what I can do about this. Updating the preview has to be asynchronous (because it can be much slower than a keypress and would slow things down). But it does run the risk of refreshing in between keystrokes like that.

    Interestingly, there is a "sweet spot", or perhaps I should say "sour spot" in typing speed vs refresh speed. If I type much faster than the preview, then it will be rare that the preview updates before a space, and immediately after the space (which is when Apple's "space bug" occurs). If the preview is much slower than my typing speed, then there will be enough of a delay that the preview waits for me to type something else after typing a space.

    I'm looking into an efficient way to avoid this....

    Thanks for pointing this out!

  2. Support Staff 2 Posted by Fletcher on 06 May, 2018 02:47 AM

    Fletcher's Avatar

    Also -- thanks for the video. Very helpful, especially at slow speed!

  3. Support Staff 3 Posted by Fletcher on 06 May, 2018 03:05 AM

    Fletcher's Avatar

    Or maybe the best solution is just to slow down the preview refresh rate from a max of 50 msec to 100 msec... ;)

  4. Support Staff 4 Posted by Fletcher on 06 May, 2018 02:32 PM

    Fletcher's Avatar

    Just pushed 4.4 b5. I adjusted the preview refresh delay to improve performance as well as reduce the jumpiness.

    (Below technical comments are for interested readers and to remind myself in the future...)

    That said -- I don't know that there is a way to 100% prevent the "space bug" from occurring:

    (For those who are unfamiliar, there seems to be a long-standing bug in Apple's WebView whereby changing this to this<space> causes the preview to jump vertically. This has been a persistent problem since the first versions of Composer, and others have documented it as well.)

    1. Option A is synchronous refreshing of the preview, which would destroy performance with longer documents with every keystroke where a refresh occurred.

    2. Option B is asynchronous refreshing (like now). I've adjusted the timing and delay settings to minimize this, but it is still theoretically possible to type at a certain speed relative to refresh timing and trigger the bug. Basically I am trying to play with statistics to make the bug rare, but can't make it impossible. Advantage -- adjusting this is really easy, though it can be trial and error to find good settings. Disadvantage -- it's not perfect, and ideal settings will vary based on user and machine variables outside of my control (typing speed and characteristics, CPU speed, number of CPU processors, other programs running at same time, etc.)

    3. Option C would be to jump through some hoops to try to synchronously and atomically grab the contents of the textview and the last character typed, and then perform the updates in the background. This would still hurt performance due to having to copy the entire contents of the text view for every keystroke, but not as badly as option A since the rest would be in the background. I would prefer to avoid this approach, but can consider it if necessary.

    4. Option D -- use asynchronous refreshing, but on every refresh compare the existing HTML with the replacement HTML to verify that a space is not the only difference between the two. This will hurt preview performance, but should not affect typing responsiveness. It would increase overall CPU usage and therefore decrease battery life (by some as yet unknown amount.) This might be better than option C, but still seems like overkill.

    For now I will try to tweak the timing settings to minimize the bug.

Reply to this discussion

Internal reply

Formatting help / Preview (switch to plain text) No formatting (switch to Markdown)

Attaching KB article:

»

Already uploaded files

  • MMD_Preview_Jumping.mp4 1.38 MB

Attached Files

You can attach files up to 10MB

If you don't have an account yet, we need to confirm you're human and not a machine trying to post spam.

Keyboard shortcuts

Generic

? Show this help
ESC Blurs the current field

Comment Form

r Focus the comment reply box
^ + ↩ Submit the comment

You can use Command ⌘ instead of Control ^ on Mac