Unfortunately, disabling the “Open comments in inspector” option does not change anything…
Could you clarify this one a bit? For myself, if I disable that option so that the inspector does not open when clicking on a footnote highlight, so that the only thing that loads is that one footnote I clicked on, then I get no UI lag from doing so, nor any lag when switching between items (since the inspector is closed).
That said, it sounds like you may have more than just this one specific issue…
Are there other technical solutions I may try ? Or practical/organizational ones in order to work with footnotes ?
As for the main issue itself, unfortunately not. We mainly only have notes on what makes it worse, and only the inspector tip for avoiding it.
But again the inline marking feature should in and of itself cause no dramatic slow-downs, so something is a bit odd there and perhaps worth exploring further. I have never seen a problem like you describe, where the whole program stops responding to the OS and goes grey, because of inline notation of any kind—and I use inline annotations a lot. There can be many dozens of them in one scrivenings session at a time. Also worth noting is that this is running Scrivener in a Windows 10 virtual machine, with ~3GB of RAM allocated to it and only two CPU cores. If anything it should be magnifying every performance issue (and generally it does).
Have a look at the test project I am attaching:
footnote_speed_tests.zip (168.5 KB)
- The project should load to ‘section b’, which uses inline annotations exclusively, and with the inspector closed. So the project should open swiftly.
- All four of the test sections are identical by the way in terms of content. They each contain 36 footnotes and a more than average amount of text.
- “section a” has had its footnotes converted to inspector notes.
Clicking on “section a” in the binder loads it immediately, again with my really horrible virtual machine specs.
I for the moment have the aforementioned Editing options disabled so that clicked footnotes open in a pop-up individually. This also reacts immediately, as does using the < and > buttons to flip through notes (you may note it periodically fails to keep itself open; that’s a bug).
Clicking on Draft, which is set up to load in Scrivenings mode, is essentially instantaneous. I see the “building” progress bar for maybe 200ms.
Now at this point we have 36 × 3, or 108 inline footnotes in the view, and 36 footnote highlights. Putting the cursor into the second section (below the empty “Red Book” divider), and adding a new paragraph operates at full typing speed for me. I specifically pressed return twice at the end of a paragraph to add a new one (sorry, Markdown writing habits in this test), and then typed for long enough to invoke word-wrapping a few times. This tests pushing all of the adornments and links around in the view in different ways.
You will find a “Notation” entry in document templates. These copies were just spammed from that, so each use of that will add another 36 inline annotations to test with. You could also select the Red and Black book folders and duplicate then until running into performance issues when editing in scrivenings in the Draft folder. Naturally it will get longer to load if you duplicate enough—no way to speed up loading hundreds of thousands of words.
There is no reason to be loading footnotes and comments if the tab isn’t showing. I mean ideally it shouldn’t take 5 or whatever seconds to load 30 notes into rectangles to begin with, ideally it shouldn’t matter, but even so it is bad practice to, for example, load all of that into graphical rectangles you can’t even see, when right-clicking on the item in the binder.