Keith just posted this response the other day in a bug-hunt thread on this topic, so with luck your lag issues are resulting from that same issue which he’s fixing for the next release. You might go check that thread over there and see if your situation seems to match. He’s also planning on making available a beta of 2.0.3 with this fix so users can test it out; once that goes up in the beta section, it’s probably worth your downloading it to see if it gets rid of the lag.
Not sure if anyone else is still having this problem but I’m running Scrivener 2.0.5 and finding the typing lag to be quite distracting.
I’ve already cleaned font caches and am about to run through the Onyx process suggested by Graybyrd but I wondered if the exact cause of the problem had been identified yet? It wouldn’t seem to be a matter of keyboard shortcuts (in my case at least) because I’m using v2.0.5.
Has there been any further discussion about this since Jan 2011 that I’ve missed?
No - there’s only one outstanding case I know of and so far I haven’t been able to get to the bottom of it. Could you please try setting up a different user account on your machine and see if the lagging occurs in that fresh account too - that will tell us if the trouble is something specific going on in your main user account, or a general problem with Scrivener on your machine.
Also, what version of OS X are you running? And, can you please take a look in ~/Library/Application Support/Scrivener/Logs and attach the Console.log file from there to your reply (fire up Scrivener and type so that you get the lag first)?
Let me know how the above goes and we can take it from there. If you’re willing to run some tests and try some special builds of Scrivener, let me know, and we can go through the process next week - I’d really like to get to the bottom of it.
Thanks and all the best,
I’ve had a few episodes of this, occurring seemingly at random. I’d finally get mad and go away and pace about the property, and then I’d (usually) return to find things back to normal. From this I began to suspect it might be the Unix maintenance routines maintaining whatever it is they maintain in the background. And sucking up resources along the way.
Just a guess, of the blessed-are-the-cheesemakers variety. But I have faith in it.
And it sorted itself out without having to close Scrivener and restart it? If so, that would fit with maintenance in that situation.
All the best,
It did, at least for me. It’s kind of the Mrs. Smiling solution (from Cold Comfort Farm). When confronted with wayward human (or computer) nature obtruding its grossness upon my scheme of life, I pretend it hasn’t happened, and after while, it has not.
Thanks for the reply, Keith.
I suspect that my problem, like Ahab’s, is intermittent and I don’t know what triggers or stops it. That makes it a little difficult to test, together with the fact (and I’m ashamed to admit this in an open forum) that I can’t touch-type, so I’m looking at the keyboard rather than the screen as I type and this must at least partly account for its intermittence (I mean it’s a bit harder to test it as methodically as I’d like).
I’ll keep one eye on it next week (by turning my head sideways perhaps) and if it occurs again will do as you suggest - new user account, scriv log etc.
I tried something after I’d sent the message yesterday: I deleted two shortcuts I’d set up in System Preferences that were specific to Scrivener. I was guessing it might improve things although if as you say the newer version uses a different routine, it shouldn’t have any effect one way or the other?
Will keep you posted.
Actually the new version doesn’t use a newer routine for keyboard shortcuts after all. The new routine turned out to cause all sorts of problems so got dropped - that would be one of the texts I would run by giving you a build with that routine, so that you could see if it made things fast. Although those routines wouldn’t be good in a shipping app, they would give me an indication of whether it was keyboard shortcut code that was to blame.
Thanks and all the best,
I too am experiencing this problem on 2.0.5
#1: I’m using MenuMeters and I can see the CPU go up as I type in Scrivener. It’s not a lot, but it’s some. Typing in a sticky doesn’t use CPU, typing this reply in Chrome does. Maybe you can make some sense of that, not sure if it’s related.
#2: It’s slow in both full screen and regular view. Same speed.
#3: This is most interesting - certain characters take longer to write. I just went down alphabet and discovered that it’s only letters N and Y that are slow. And they are significantly slower.
In the same amount of time, I can type:
Also going left and right through the text using arrows is as slow as N and Y.
But the N and Y keys work fine in this reply, so it’s specific to Scrivener.
Also, the numbers 1-9 are as slow as the N and Y keys. 0 is fine. Moving left/right/up/down is fine in Full Screen, but laggy in normal mode.
Thanks for the thorough info. The fact that this occurs only with certain keys does suggest that it has to do with keyboard shortcuts - it suggests that for some reason, on your system, the commands in Scrivener’s menus associated with those keys take a little while to validate. (There’s a flaw in the way menus work in OS X in that every time you type a letter, OS X looks to see if there is a menu item connected to that shortcut key, even if no modifier keys are pressed - which means that the menus get validated for every letter you type, and there’s no way to tell OS X that there’s no need to do this except for modified keys.)
The 1-9 keys are associated with script elements in the Format > Scriptwriting > Change Element To menu, and this is interesting because in order to check the script elements Scrivener checks a file on disk. This was my first suspect when I first looked into this problem - but I sent a build to a user with this issue that didn’t check the file on disk and he reported that the problem continued. But maybe it was part of the problem after all. The N and Y keys are odd though. Y is only associated with Show Script Elements Menu and Bibliography/Citations…, neither of which should be slow to validate.
Do you have a bibliography manager set?
Are you in script mode or regular text mode?
Have you defined any custom keyboard shortcuts for Scrivener via System Preferences?
Likewise, N is just for new projects and adding new text and folder files… Although validation for the latter may be quite complex.
What system are you on?
Would you be willing to run some tests and to try out some builds of Scrivener to help me narrow down the issue? If so, could you please drop me a line at email@example.com and I’ll get back to you tomorrow (Monday) with some things to try to see if I can zero in on the cause.
All the best,
*** UPDATE ***
Actually, could those of you experiencing this problem also try downloading and running this version of Scrivener:
This version disables the code that checks for keyboard equivalents in the main menu. That will mean that keyboard shortcuts won’t work properly in this build, but that’s not important as this is just for testing - could you please tell me whether typing is fast in this version? If so, that confirms that the keyboard shortcut code is the issue.
Thanks for prompt replies.
I’m on Snow Leopard 10.6.6, 1.6 GHz, 1G ram. My other machine, which is also 10.6.6, but is a 2.8 GHz with 6G ram isn’t experiencing any issues, but I use the slower laptop for writing.
I don’t know what a bibliography manager is.
I’m in regular text mode, not script writing mode.
The version you attached works perfectly. Number keys, Y, N, all work fine in both full screen and regular mode.
When would you expect it to end up in an official release?
Thanks for testing. As I explained above, this is just a test and isn’t suitable for any proper release - it completely breaks keyboard shortcuts and was solely provided for the purpose of testing whether it is indeed the keyboard shortcut code that is causing the slowdown. The problem is that the keyboard shortcuts code is down to Apple - this version just bypassed it. I’d therefore be very grateful if you could test out some other builds as I try to narrow this down seeing as I can’t reproduce the issue myself. Unfortunately I won’t be able to get any fix into an official release until I have a volunteer to test some further builds.
P.S. One other question: do you have any custom scriptwriting formats?
I don’t know what a scriptwriting format is, so I would assume no.
My file is about 45,000 words broken up into 26 chapters. Very straight-forward. No custom scripts or folders or pictures. The only customizations I did were to turn full screen view black, some font changes and some compile changes (the Novel preset had some odd default settings like monospace default font and converting italics to underline).
I made the changeover into Scrivener only a few days ago, before that I was using Vim for writing.
I’m extra sorry that your experience so far hasn’t been as good as I would have hoped then!
Could you please try the following three builds and let me know how each one works for you?
(I wouldn’t expect this one to make any difference, but it’s worth a try to rule out validation code related to menu items and shortcuts.)
(This one is the one that I would have expected to have fixed things but the other user reported that it didn’t. I’d therefore be very grateful to know whether this has any effect on speed on your machine.)
(If the second build makes a difference, I’m not sure if this will help further or not, but it would be useful to know so that I can rule out another area of code.)
Many thanks and all the best,
P.S. Also, I’d be grateful if you could test in a new user account on your machine to see if the slowdown happens there too. Thanks!
No worries, I appreciate you being on top of it.
ScrivNoValidation: slow 1-9, Y, N in normal and fullscreen
ScrivNoScriptStuff: works fine
ScrivNoScriptNoLayouts: works fine
Thanks for naming them differently, by the way. It makes it easier.
I just set up this machine a few days ago, so the user account is pretty new.
Many thanks Andrey, this is great news. Strange that the other user reported the code I suspected made no difference, but good to know that it has fixed things for you. I’ll go ahead and optimise the code I omitted from the two builds that worked fine for you so that things should be fast for you at least.
All the best,
Sorry that I can’t contribute anything useful to this test. After deleting the Scriv shortcuts I’d set up in system preferences I typed a couple of paragraphs and the lagging symptoms were not present but it wasn’t really grounds for a proper assessment as I’ve previously only noticed them in the course of a day’s work.
There wasn’t much point trying the non-shortcut build then but I did go back and set some system prefs shortcuts again and then after typing more paragraphs, found no apparent change in Scrivener’s performance.
Glad to hear that Andrey’s problems seem to have been fixed. I think the best I can do is to continue working this week on my 2.0.5 release and do the tests you’ve suggested only if and when the problems reappear - otherwise I’ve no basis to measure results by.
I don’t have any custom scriptwriting formats but I do have a few custom layouts - I mention this because I notice one of your builds was named ‘nolayouts’.
I’ll press on and see how things go this week.
Thanks for your diligence. Must keep you busy on weekends!
Thanks Andy. Layouts may be an issue, I realised. Both the scriptwriting formats and layout code relies on checking for files on disk, so it may be that for some reason the computers affected have slow disk-checking issues. I’m going to move the relevant code into a different place that won’t be called every time a key is pressed, so now that Andrey has tested the files and you have confirmed you have custom layouts, I hope to fix this for 2.0.6.