The search field of the toolbar is noticeably larger than the other one. This is good … for my old eyes.
Unfortunately, the toolbar’s search box is very slow to respond to typing or deleting text. Is this only the case for me?
My guess is that the problem is a result of having both search tools open at once, there may be some kind of cross-feed there, as this isn’t intended to be working that way. When the search tool is put in the toolbar, it is meant more to work like it has been moved there.
All methods that would normally open the sidebar search tool should be redirected to the toolbar instead, and thus you would never see it. I’m not sure how you got it, but closing it should help (and maybe reload software to get rid of any internal UI interface components left “open” but invisible).
If you know what opens it, let me know, as that a hole that needs to be plugged.
I had this suspicion too. But even if I close the other search field, it doesn’t change anything.
In your case, both fields respond equally fast to text input?
edit: If the toolbar is not visible ⌘⇧+F shows the small search window. If you leave it open and show the toolbar, the big one will be shown as well… If this was added to the toolbar
Ah, okay, that’s probably one condition we can’t really handle (adding the widget to the toolbar, or hiding/showing the toolbar) as that is all system level stuff.
And as noted, this happens after fully restarting Scrivener and deliberately not engaging this condition, just searching from the toolbar? If so I have no speculation on why that could be. There is no difference that I can see, testing against a 150k word test project for a very common word.
Could be hardware/OS version related, really. I’m looking at it from an M2 running the latest OS. Maybe I’d see a difference in macOS 10.14 on a 2016 laptop, for example, but any difference is being completely obscured by the much newer hardware.
Okay, thanks for testing, @AmberV. Then that’s just my bad luck. The difference is really significant. In the big search box one letter per second is typed. 
I would have liked to use it because I can see it better, but when it’s that slow, it’s not an option. 
The only off-hand thing I can think of is that you are applying some accessibility settings to the UI: from what I can see the high contrast option. I realise turning that off probably isn’t something you would want to live with, but as a diagnostic it might give a clue—and any other settings in there that might make a difference. Oh, one thing I do always turn on in there is the setting that wipes out all that “glass” junk. “Reduce transparency”, I think it is called. It would be odd if that is of impact since I don’t think any transparency is involved between these two areas, but maybe see if turning that on helps.
Okay, I tested all this with and without contrast/transparency … unfortunately it changes nothing. The small search field is fast, the big one is slooooooooooooow. I can live with it 
Before I do useless stuff. Do you think it might help if I reinstall Scrivener?
Before you try that, I would try searching in another project, like the interactive tutorial, just to rule out any kind of scale issues. My test was for a typical book sized project, but maybe problems can become more obvious if there is more text going on (search will slow down the more there is to search through, for obvious reasons).
But otherwise, it might help. It’s impossible to say for sure, but it wouldn’t hurt anything to trash one copy and replace it with another. Some weird interface issues are fixed by doing that.
With the interactive tutorial, both search fields are equally fast. The small one is only slightly faster than in my big project (2 GB), although the interactive tutorial is only 5 MB.
Of course, but shouldn’t the search slow down in both fields to the same extent?
What do you mean exactly? Should I duplicate my 2 GB project and test the two search fields?
You were asking about reinstalling the software, that is what I was responding to. I can’t think of any reason to duplicate the data on the disk and remove one of the duplicates.
Of course, but shouldn’t the search slow down in both fields to the same extent?
I don’t know why there seems to be a difference, I’m just getting the data recorded to be looked at. Every clue helps make something easier to look into than the simple fact that one is slower than the other. The digging you’ve done helps narrow that down to one thing essentially: huge projects can help illuminate an optimisation issue.
Whether it can be fixed is another matter.
Thanks for the report!
Ah, ok, then I misunderstood you, sorry. I’ll try reinstalling Scrivener and report back.
What I also tried in the meantime is to create a copy of my project and test it. You already guessed it … no difference.
What’s astonishing is with the small search box, the difference is minimal whether the project is large or small. But with the large search field the difference is huge, at least for me. No idea what that could mean. I leave that to you to interpret.
Thanks for your help @AmberV
1 Like
Do you have Scrivenings mode turned on (so that your whole manuscript is loaded into the editor pane) when you are seeing this effect?
No, Scrivenings mode is turned off.
1 Like