Horrible delay in words appearing when typing

This might be my Mac (using an old G4 powerbook running OS 10.4.11), but this is new in Scrivener 2.0: when I type in an older fairly large project, I am finding that sometimes there is a long delay between typing and the words or other edits appearing on the screen. It isn’t consistent and didn’t happen when I created a new project to experiment; biggest problem was in editing a long page that has a bit of formatting (different fonts) where I’m doing a running journal and so add new material from the top instead of from below, but not sure that is reason. Never ran into this before on earlier version. It fits the general slowness in the other area that bugs me: closing documents of that size result in the new long lag time while the zip is being built (which is redundant for me, since I store my originals on Dropbox anyway.)

As I say, I do have similar issues with some other software: Tinderbox’s mapping function has been doing this for a few months since they did an upgrade, in which I may create or drag something on a map and find that I have to click somewhere else on the window for the change to appear (which ruined the mapping for me). But till I can get a newer Mac, not sure what I can do about it.

I don’t want to have to work in Textedit and paste into my Tinderbox project, so hope this is just a rare occurrence. thought you’d want to hear about it, though.

A lot of optimisation has gone into the typing code for 2.0, so it’s unlikely that 2.0 is objectively slower in this area than 1.x - it is much faster for most users - so something else must be at play here. If you paste one of these long documents that lag into TextEdit and start typing, what is the delay like there? Also, do you have any third-party programs that intercept typing at all?

Why don’t you turn this option off then? (Preferences > Backup)

Definitely - I’d like more information if you can think of any though, because a lot of the slowdown code has been stripped out for 2.0, as I say, and most users (with one or two exceptions) have reported 2.0 being much faster, which is the expected result.

Thanks,
Keith

Thanks, Keith.

Not sure if I have any else to add, except that taking your suggestion I did paste the long doc I’m noting the slowdowns on, into a Textedit doc; it works just fine there. In fairness, this one is a long-ish (it says 25 pp, 7000 words) document with a few pics pasted in (kind of a journal of the project). But it’s definitely a change from Scriv1.

I also note it being slow even in the binder sometimes, clicking on a doc and having a bit of a lag. Seems like whatever is different, it just all gets processed more slowly on my old clunky Mac. Alas, not sure when I can get a new one, so I may have to just do some workarounds till then. As I say, I have a bit of a lag with Tinderbox also, and they haven’t been able to reproduce my mapping delay problems at Eastgate.

I have a pretty fast MacBook Pro, and I am getting delays now and then with Scrivener. One that is very annoying is that I type a letter and nothing happens, and when I type the subsequent letter, both show up at the same time. I think that this is associated with typing below an image (I use medium-sized png’s, so the pics themselves should display quickly). If I can come up with a test case, I’ll post it.

A

Scrivener 2.0 was fast up to now, but this morning I experienced periods of slowness as well: I type (and I am typing with two fingers only, not at all fast!) and the letters appear as if coming up through white syrup.

From time to time it got better, but in the moment it’s here again, going slower than ever.

I will take resort to a trick every former Windows-user knows only too well: Reboot the machine.

See you later.

Reboot didn’t help.

Vague observation: Might it be possible that the delay appears only in Scriv projects that had been created in Scriv 1.x and updated? When I open a project I created after the installation of Scrivener 2.0, everything runs smoothly. It’s my old ongoing projects and projects I created from my own old templates where I have the delay in the moment.

There is no difference between a project that has been updated and a project that has been created in 2.0, so that’s definitely not the problem.

Please take a look at the console log (~/Applications/Utilities/Console.app) to see if anything is being output there - it may be that an exception is getting thrown while you are typing.

If that reveals nothing, can we arrange for me to take a look at the project? You can drop me a line on the beta-testing e-mail address.

Thanks,
Keith

Sad to say, but the slowness of typing in Scrivener starts to become a severe hindrance. :frowning:

This morning I was writing, but the letters came so slow that for a moment, I was thinking: “Maybe I better type in TextEdit and paste everything into Scrivener later?” Then I realized what nonsense this would be, so I restarted my efforts to nail this bug down.

Observation 1: No delay when writing in TextEdit. It’s only Scrivener.

What do I find in console? No message during typing, only this:

02.12.10 06:11:46 Scrivener[288] Custom ColorPicker class with name .DS_Store could not be loaded.
02.12.10 06:43:16 Scrivener[288] dealloc arbitrary collections table controller!

Does this say anything?

Hypothesis: As most users don’t complain about this, it has most probably something to do with my configuration, espacially the additional tools I use.

First suspect is TypeIt4Me, my most indispensible tool. (Anybody here using this without problems? Any comments welcome!) Second suspect is Keyclick, which provides the nice typewriter sound I sometimes like to hear while typing.

However, simply disabling/pausing these applications makes no difference. Scrivener remains slow as syrup.

I will make a list of all my startup objects today and start tomorrow with shift key pressed (no startup objects) in order to see how Scrivener behaves then. If everything is okay then, I’ll start the other tools one after the other. (Today I won’t have the time.)

Observation 2: The slowness is not immediately there, it comes only after a while.

Andreas,

I use Keyclick and have no delays. I don’t use TypeIt4Me or any of its rivals currently. However… I have noticed that this type of text-expander application has given problems to users of Dragon Dictate for Mac. What is the significance of this for Scrivener? If it’s the source of the issues you’re facing (and that of course is still unclear), users of TypeIt4Me or its rivals concurrently with Dragon Dictate have found that it isn’t sufficient to pause or disable the text-expander application. The application still causes interference because something residual remains. It has to be quit and Dragon Dictate restarted. If nothing else, this may help identify the problem, or identify what it isn’t.

H

I also use keyclick without any problems.

David

This morning, I started my iMac with shift-key pressed in order to load no startup objects.

Then I started Scrivener and wrote for a good while (because I had the impression that the delay does not appear immediately), and everything worked fine and fast.

Then I started TypeIt4Me, and there it was: All characters are going through white syrup again before they appear in front of me.

So, it’s TypeIt4Me that does not go together with Scrivener 2.0. That’s sad, because I rely very much on this tool, which used to work in all other programs flawlessly up to now.

I’d like to hear from other TypeIt4Me-users whether they experience the same problem.

Does TypeIt4Me have an exclusion mode? Can you tell it to not monitor some applications?

Ioa, this thread is also pertinent: [url]https://forum.literatureandlatte.com/t/typeit4me-typinator-what-works-together-with-scriv-2-0/10043/1].

H

Status report:
On Keith’s suggestion (I harassed him with an extended console log of my experiment via email) I created a fresh account on my machine with nothing than standard setup, Scrivener and TypeIt4Me - and the delay was not there! :blush:

So, it must be something else in the configuration of my tools that creates the trouble. I’ll reproduce my setup one by one in the new account, maybe I’ll stumble over the evil-doer…

Unfortunately, I wasn’t able to reproduce the delay in my test environment. I added all my tools, text expander, whatever, but Scrivener works flawlessly there. I have no idea what to do anymore.

The only reliable fact is: When I quit Scrivener, restart it and type, everything works fast. Until I move the cursor to another place - by mouse or by cursor: Every word I type afterwards appears character … by … character … by … character … by … character …

The delay seems not to be the same every day. Yesterday, for example, it was so horrible that I practically couldn’t do any real work in my Scrivener files.

This is even the case if I quit my session and log in again with shift key pressed - which, in my understanding, means that none of my tools are active. So, they are most likely innocent. It must be something with my system that’s different and causing the problems.

Scrivener 1.54, however, works lightning-fast as ever. Go figure. Only that it looks - now that I got used to the 2.0 interface -, well, so very much 1.54.

Any ideas, anybody?

All right, if a spare account solves the problem and it isn’t a running background process that are interfering, then the next thing to check is caches. I recommend Onyx. Run a user-level (we know it isn’t system level since the spare account worked fine) cache wipe and then reboot.

If that doesn’t work, the next thing to check for is preference corruption at some level. The easiest way to check for this is to quit everything; then just drag your entire Preferences folder out to the Desktop and then log out and back in. Everything will be vanilla again; start up Scrivener in trial mode, and see if you can replicate the problem. If everything runs clean, then you’ve probably got a corrupt preference file somewhere. The fun part is finding it. You could try some of the more obvious ones first, but as you copy drag preferences from the Desktop backup into your live Preference folder, if nothing seems to replicate the problem it might be easier at this point to just migrate your data over to a fresh account and close the doors on the old one. There are many hundreds of preferences, and a large number of these can impact other things even in oblique fashion, finding the one problem file could take a while—but then, so does making a new account, copying everything over, and setting everything up again the way you like it.

Thanks, Ioa. I’ll try the cache wipe first and the Preference Hunting Game afterwards …

This morning, I started up my computer with shift key pressed in order to check again whether Scrivener will work properly or not when rebooted from cold. Well, it didn’t. I called up Console and copied the whole log (which containes some rather dubious sounding messages) so far. Maybe someone with more knowledge about the inner life of Mac OS X might spot something suspicious?

20.12.10 10:24:55 com.apple.launchctl.System[2] launchctl: Please convert the following to launchd: /etc/mach_init.d/airport_wps.plist
20.12.10 10:24:55 com.apple.launchctl.System[2] launchctl: Please convert the following to launchd: /etc/mach_init.d/chum.plist
20.12.10 10:24:55 com.apple.launchctl.System[2] launchctl: Please convert the following to launchd: /etc/mach_init.d/dashboardadvisoryd.plist
20.12.10 10:24:55 com.apple.launchctl.System[2] launchctl: Please convert the following to launchd: /etc/mach_init.d/pilotfish.plist
20.12.10 10:24:55 com.apple.launchd[1] (com.apple.blued) Unknown key for boolean: EnableTransactions
20.12.10 10:24:55 com.apple.launchd[1] (com.apple.distccdConfigd) Unknown key: SHAuthorizationRight
20.12.10 10:24:55 com.apple.launchd[1] (com.apple.usbmuxd) Unknown key for boolean: EnableTransactions
20.12.10 10:24:55 com.apple.launchd[1] (org.cups.cupsd) Unknown key: SHAuthorizationRight
20.12.10 10:24:55 com.apple.launchd[1] (org.ntp.ntpd) Unknown key: SHAuthorizationRight
20.12.10 10:24:55 com.apple.launchd[1] (org.x.privileged_startx) Unknown key for boolean: EnableTransactions
20.12.10 10:25:04 com.apple.launchd[1] (com.apple.distccdConfigd[32]) Exited with exit code: 255
20.12.10 10:25:05 com.apple.launchd[1] (com.apple.aslmanager) Throttling respawn: Will start in 3 seconds
20.12.10 10:25:07 com.apple.launchd[1] (com.apple.aslmanager) Throttling respawn: Will start in 1 seconds
20.12.10 10:25:54 com.apple.launchd[1] ([0x0-0x5005].com.wacom.TabletDriver[79]) Exited: Terminated
20.12.10 10:25:54 com.apple.launchd[1] (com.apple.UserEventAgent-LoginWindow[75]) Exited: Terminated
20.12.10 10:25:54 com.apple.launchd[1] (com.wacom.pentablet[74]) Exited with exit code: 255
20.12.10 10:25:54 com.apple.launchctl.Aqua[87] launchctl: Please convert the following to launchd: /etc/mach_init_per_user.d/RemoteUI.plist
20.12.10 10:25:54 com.apple.launchd[85] (com.apple.AirPortBaseStationAgent) Unknown key for boolean: EnableTransactions
20.12.10 10:25:54 com.apple.launchd[85] (org.x.startx) Unknown key for boolean: EnableTransactions
20.12.10 10:25:54 com.apple.launchd[1] (com.apple.aslmanager) Throttling respawn: Will start in 10 seconds
20.12.10 10:25:56 com.apple.launchd[85] (com.apple.CSConfigDotMacCert-@me.com-SharedServices[88]) Exited with exit code: 1
20.12.10 10:25:56 com.apple.FolderActions.enabled[89] launchctl: Error unloading: com.apple.FolderActions.folders
20.12.10 10:26:01 Dock[99] _DESCRegisterDockExtraClient failed 268435459
20.12.10 10:26:17 Dock[99] [QL ERROR] Generator database update takes too long… we will use what we currently have
20.12.10 10:26:17 Finder[106] [QL ERROR] Generator database update takes too long… we will use what we currently have

First feedback: Cache wipe didn’t change anything.

Same behaviour: I start Scrivener, type away - everything is fast - I touch a cursor key, one row up - and again … the … characters … come … one … after … the … other … when … I … type …

Unfortunately, no time today for the next step. They say there’s a certain “Christmas” coming, and that it needs some preparations (buying LOTS of food, cleaning the house, writing postcards etc.). :laughing:

This thread hasn’t been posted in for a while, but I thought it would be silly to start a new one for the exact same thing.

I’m experiencing the same problem. I’m only noticing it in full-screen mode. There are no relevant Scrivener logs in Console.app (the most recent one I have is from yesterday wrt. computing a thumbnail, but I think that was from a non-supported filetype I have in my project). I experienced the issue today and nothing was logged.

It’s not a big deal for me; I just hit space + backspace to get it working, or else type through and it “solves” itself. I just thought it would help if it could be nailed down to full-screen mode, but maybe I’m unique in that.

Just to confirm: are you using version 2.0? (I’m almost certain you are from your other posts, but just checking.) I ask because 1.x did have a delay in full screen (which should be fixed in 2.x).

Regarding the delay in typing that some users have been reporting in 2.0, though, I am hopeful that I’ve solved it - and it affected moving the cursor keys through the text, too. It is down to how OS X finds keyboard shortcuts in the menus. OS X can check with the individual program about what should appear in the menus so that the program can build or modify them dynamically. Thus, when you go to open a menu, OS X will check with the program what should appear in that menu, in case you want to change anything - this is how you can have “Show” or “Hide” in the menu, for instance; the app can check whether something is visible, and if so modify the menu to say “Hide”, otherwise have it say “Show”. But it also allows the application to clear and rebuild whole menus which may change depending on various factors - such as Scrivener’s “Go To” menu and suchlike. So, OS X needs to check for this whenever a menu is opened, or whenever a keyboard shortcut is pressed, at which point the program can do the work to update the menus.

However… It seems that OS X checks these things whenever you press a key even if you aren’t pressing any modifier keys. If the key you press is used in a shortcut anywhere in the menus, even if you don’t press any modifier keys (shift, opt, command etc), then OS X will call on the program to update the menus. And Scrivener uses just about every letter and number in a keyboard shortcut somewhere, and it does a lot of rebuilding. The result is that every time you type a letter, all of the menus get updated - every time. That’s a lot of work going on as you type.

Unfortunately OS X has an all-or-nothing approach here. The slowness only happens if OS X needs to check for keyboard shortcuts - if you tell it not to, then there’s no slowness. So, you can either turn off user-defined keyboard shortcuts entirely (it doesn’t affect build-in shortcuts), or deal with the slowness. Painful! So for 2.0.3 I have pretty much implemented my own keyboard shortcut-checking code rather than relying on OS X’s default behaviour.

AndreasE has already tested this and reports that it fixes his speed issues. In the next few days I hope to post an early 2.0.3 build in the Beta Testing section of the forum so that other users with this issue can test to see if it helps, too.

Out of interest, have you set up any keyboard shortcuts in the System Preferences? I’m wondering what the difference is between those who have slowdown and those who don’t.

Thanks,
Keith