More bouncing
I just had beta 24 start bouncing again (I haven't seen one today until now). I've been in the file for about a half-hour. As before, I'm editing towards the end of the file, and as before, when I started typing on a new line around the middle of the screen, it jumped it down to the bottom. And, as before, once it starts, it keeps doing it, and it does it everywhere in the file (I moved up towards the top of the file, and it continued to do it there as well.)
Comments are currently closed for this discussion. You can start a new one.
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
Support Staff 1 Posted by Fletcher on 30 Aug, 2017 09:08 PM
It took some doing, but I finally found one way to reliably cause this.
Create a long document (e.g. 30,000 words or 200,000 characters). I
couldn't make it happen in shorter (faster) documents.
Scroll editor such that the cursor is off screen.
Use arrow keys to move around.
This triggered a remaining race condition between the two types of
scrolling, one from my code and one from macOS itself, which caused the
jumping behavior as the editor tried to get back into position.
I rewrote a couple of steps, and it seems to have resolved this issue.
See if b25 is better for you when I release it.
2 Posted by Vince Rice on 30 Aug, 2017 09:20 PM
Excellent, look forward to it! At the moment, the only document I'm working on is a fairly good-sized one (the size of the test file I sent, i.e. 50K+), so that's probably why I'm running into it fairly consistently. (Although it did take longer to appear in B24.)
Support Staff 3 Posted by Fletcher on 30 Aug, 2017 09:50 PM
PS> You haven't mentioned anything new about the preview pane jumping around inappropriately. Is it doing better for you?
4 Posted by Vince Rice on 30 Aug, 2017 09:56 PM
I haven't noticed it jumping lately (separately from the editor jump), but it does still stop scrolling occasionally (just happened, AAMOF).
5 Posted by Vince Rice on 30 Aug, 2017 10:09 PM
As I think I described earlier, the "preview stops scrolling" happens when doing multiple consecutive scrolls (like you do when moving around a large document). I haven't seen it when scrolling from a dead stop. It happens either direction, i.e. when scrolling the same direction (e.g. scroll once, scroll again, scroll again; freezing can happen on second or third scroll) or when switching directions (scroll once, scroll twice, it gets to the top of the file, scroll the other direction; it freezes when going the other direction).
When it freezes, it sometimes stays frozen on additional scrolls (i.e. before it stops), it sometimes starts back up. Stopping completely and scrolling again always starts it back up (at least I'm pretty sure it's "always").
> On Aug 30, 2017, at 4:55 PM, Vince Rice <[email blocked]> wrote:
>
> I haven't noticed it jumping lately (separately from the editor jump), but it does still stop scrolling occasionally (just happened, AAMOF).
>
>
>> On Aug 30, 2017, at 4:50 PM, Fletcher <[email blocked] <mailto:[email blocked]>> wrote:
>>
Support Staff 6 Posted by Fletcher on 30 Aug, 2017 10:17 PM
The other thing you can do to "reset" the sync scrolling is to check
which modifier key is configured in preferences. Normally that modifier
toggles sync scrolling on. But when its set to always scroll that way,
the modifier toggles it off.
Also, try scrolling the other view when it freezes.
I've briefly looked into a cause for this, but haven't found one yet. I
also prioritize this issue behind the other issues we've been
discussing. But since my to do list for 4.0 is drawing to a close, it
is moving up the remaining items. ;)
7 Posted by Vince Rice on 30 Aug, 2017 10:30 PM
When I'm talking about this, I'm always scrolling the editor view, and it's always the Preview that's freezing. (I don't generally scroll Preview; I don't do it generally and I don't do it in MMD specifically because I hate it's top/bottom of file behavior.)
It never stays stuck forever, just while the current scrolling stays in progress. As I said last time, once it comes to a full stop, starting scrolling again will cause it to re-sync. The best I can do to describe "full stop" is that the scroll thumbs disappear. IOW, when you start scrolling, the thumbs appear on both sides. If you scroll again while it's still moving, or, it's stopped moving but the thumb is still visible, then it's not "full stopped" and the Preview can freeze, and, as long as the thumb stays visible, it can stay frozen. But, once you bring everything to a full stop by stopping scrolling and the thumb disappears, when you start scrolling again it will re-sync.
In B24 and before, once this starts happening, it's start being pretty consistent.
I just dl'd B25, and in exercising it pretty good for 2-3 minutes, it hasn't happened. However, I haven't done any editing in the file yet, and it may be that it's related. Or maybe the bouncing issue fixed this, too (hey, stranger things have happened!). I'll let you know more tomorrow after I've used B25 for a while.
8 Posted by Vince on 30 Aug, 2017 10:41 PM
I replied to this via email but it hasn't gotten here yet. I said that it hadn't happened in B25 after 2-3 minutes of exercising it, but I hadn't done any editing yet.
As soon as I hit send and went back to B25, it happened immediately (I still haven't edited anything). And, as before, once it started, it continued to happen pretty consistently.
That's pretty weird. Any way it could be time related, i.e. after X minutes in a file? (That's a rhetorical question, you don't have to answer it. :) )
Support Staff 9 Posted by Fletcher on 30 Aug, 2017 11:12 PM
Hopefully fixed in 4.0b26
Fletcher closed this discussion on 30 Aug, 2017 11:12 PM.
Fletcher re-opened this discussion on 30 Aug, 2017 11:20 PM
Support Staff 10 Posted by Fletcher on 30 Aug, 2017 11:20 PM
(Your last 2 messages got shuffled to spam folder, hence late reply)
It's not time related. It could be document length related, or more
precisely, a longer document may allow more of a delay to notice.
But there was an issue where an "improperly registered scroll" could
trigger the sync map to be reset, which can take a moment to regenerate
on a longer document. After the current scrolling action ends (as you
note), the map is regenerated and all is well. At least until it
happens again.
As per other message, this particular bug is fixed for b26, so hopefully
that will fix the behavior you're seeing.
Fletcher closed this discussion on 30 Aug, 2017 11:20 PM.