Laggy scrolling

Scrivener Scrivener for macOS
,
108

To clarify, my response before was very specifically in relation to our contact at Apple, who functions more in a PR role. I thought I made it abundantly clear that if we found a reproduction, and it was something we couldn’t fix, that we’d report it through the proper channels.

So I find it puzzling to come back to this thread and find the specificity completely stripped from what I said, such that what I actually said: “If it is determined that is the nature of the problem, [the bug reporting system] is where it will be filed though, absolutely!” somehow has been transmuted into “…it is not [Apple’s] role to hear about every bug we come across…”.

The new account twist is very interesting, especially in combination with another thing we discovered recently. Someone reported that messing with the tracking/scrolling speeds in System Settings seemed to improve things, and that’s the kind of thing a fresh new account would “reset”. Otherwise, when a blank account changes behaviour, it’s always a good idea to go through all of the tools you tend to run in the background on a regular basis. Stuff like BetterTouchTool in particular, that would modify input devices at a deeper level, would be high on my list of things to check. I’ve had BTT induce bugs before (like the scroll wheel not working at all after waking from sleep, until I restart BTT).

I feel like that has been suggested before, but if not, I should have thought to.

3 Likes
109

I’m not sure how anything was ‘transmuted’, given that this is a direct quotation from your own post.

From what I understand (and please correct me if I’m wrong), the problem has been established to be a system level issue that L&L cannot fix, which suggests that this bug ought to be filed with Apple. I’m still not clear from what you’ve said whether this has actually been done.

This bug is close to a year old at this point, and it remains a chronic aggravating problem for those affected. Perhaps for the slower members of the audience you can spell out whether there is a high level of confidence that the bug is indeed Apple’s problem and that they are aware of the fact. If this level of confidence does not exist, perhaps you might help us understand why this remains the case after ~11 months.

1 Like
110

I have given up on waiting for a fix for this and wiped my MacBook and gone back to an earlier operating system (Big Sur at present, but I’ll test out which later ones also work).
I do have the luxury of using my Mac solely for Scrivener, so I understand that it is probably not an option for many people, but I think it’s the only realistic solution at present and for the foreseeable future.

1 Like
111

Except that it’s not. For one thing you cut off the second part that directly contradicts your false version, and secondly you put a word into my quote that I did not use, to broaden the statement so far that it went from talking about one single person to the entire company.

I came here to clarify what I said, since it seemed there was some confusion, and your response is basically: your clarification isn’t accurate? I’m not going to entertain you any further if that is the hill you are going to stand on.

Everything else you ask is stuff I’ve already answered.

2 Likes
112

I’m sorry if I’ve misunderstood your meaning, Amber. I’m simply doing my best to try to understand when this bug might actually be fixed. I put ‘Apple’ in square brackets to indicate that was my understanding of what you said, rather than part of the quotation itself. I am happy to accept that this is my own mistake. From your response I’m intuiting that the bug has indeed not been filed with Apple.

Has anyone at L&L installed Scrivener on an M1 laptop to reproduce the problem? Surely there must be such a machine kicking around somewhere? This might be useful specifically because I’m finding what someone above said is true, in that the problem is not really lag, per se. Rather (at least as I’m experiencing it), the problem is that each scroll command is uninterruptible by the next, so that if you scroll up and then try to stop, the stop command processes only after the initial scroll completes of its own accord. Assuming this is what’s going on, the question would be what specific process is preventing the interruption.

I note also that this effect is not limited to scrolling. If I execute a scroll command and then immediately try to switch into full-screen mode, the full-screen command executes only after the scrolling finishes of its own accord. The scrolling cannot be interrupted even by a non-scroll command.

I also note that as others have observed, the effect is completely absent in full-screen mode, so that could serve as another clue as to the source of the problem.

I have uninstalled BetterTouchTool as per your suggestion, but this had no effect.

1 Like
113

All right, no biggie, I just wanted to be sure it was understood that if we can narrow it down to a clear cut Apple bug being the problem (which usually involves creating a very simple test program for them and detailed notes on how to trigger it), then we will. There is no reason not to, and we’re the sort of outfit that will even pay for premium support tickets if we run into something baffling.

But yes, as you note, we don’t know yet whether that is the case or if it is something that can be fixed within Scrivener—and that’s not mutually exclusive either. Sometimes we can report a bug to Apple but also patch around it while we wait for a fix. It seems there is an expectation that we should report without an understanding of how to trigger it, but that doesn’t help Apple and more likely than not will result in the ticket being closed for lack of reproduction.

By recollection, I do think the main machine used to build Scrivener is an M1 (though it is not a laptop), but I think it might require more than just that to see it. I’m not even sure if that’s necessary, it may be some people here are seeing on M2.

Given how a clean test account has been reported by multiple people to avoid the bug, that heavily implies there is some amount of configuration involved, to use the term loosely. This is just an example, but say everyone that sees the bug has the “natural” scroll direction disabled in their track pad settings. It’s likely more involved than that, and it may take more than one switch to trigger it, it’s impossible to say for sure, but you can see how difficult it gets to reproduce a problem if one or two of the hundreds of checkboxes in System Settings might be necessary to have set one way or another (never mind third-party utilities also being a part of “configuration”).

What I would suggest to anyone that has the time, is to log into this test account and go through setting things up the way you normally prefer. Start with the obvious things, like track pad settings, display scaling and so forth, and be sure to test between each toggle so it is clearer what it takes to trigger it. This the approach I take when I can trigger a bug in my normal account, but not in a test account. If I can figure out what it takes to make it start happening, then I have much more luck communicating the problem to the developer. So any help there that anyone can provide would be greatly appreciated!

If I execute a scroll command and then immediately try to switch into full-screen mode, the full-screen command executes only after the scrolling finishes of its own accord. The scrolling cannot be interrupted even by a non-scroll command.

Yeah, someone posted a really good video above, showing how it’s really a problem of events being queued one after the other and playing out fully before any kind of interactivity can be resumed. I’ve got that linked to in the ticket. Before that, I had kind of misunderstood it to be a one-event lock out, which is something I mentioned having seen years ago on iOS mainly. This is something worse though.

The full screen clue is pretty weird, honestly. There shouldn’t be a fundamental difference in how Scrivener is doing anything, in that condition. It’s simply requesting the same code be run in this special environment. Do you mean Composition Mode, incidentally? Because that would make a lot more sense as that editor is far simpler than the main project window editor, and that is what more people have reported, and we do have that noted as factor.

I have uninstalled BetterTouchTool as per your suggestion, but this had no effect.

Okay thanks for checking that.

2 Likes
114

Yes correct. I meant composition mode.

Full-screen mode has the same problem as normal mode.

115

Signed up to say I am also having this problem and I am so frustrated with it that it caused me to search online for help. Seeing this thread STILL without a solution is mind-numbingly disappointing. I’m about to start asking for refunds at this point. This is unusable, and no I am not going to change all my trackpad settings for it or it will make the rest of my computer use just as insufferable. I am waiting for this application I paid good money for to ACTUALLY function the way it should. I am having this same scroll issue, as well as lines of text randomly disappearing and reappearing. Im beginning to lose all faith I had in this app and am no longer confident its even keeping any of my writing or documents safe. I want a refund and am moving back to google docs, they have tabs now. Maybe if everyone started asking for refunds they’ll start giving a shit about finding a solution for this. This is absolutely ridiculous. There is no reason why this should STILL be an ongoing problem. ITS BEEN AN ENTIRE YEAR. I’m fed up.

2 Likes