Comment 3 for bug 2065501

Doing some more testing now, I see that my main problem is probably that small but significant delay/latency between requesting a new search and qpdfview actually beginning that search (or seeming to, anyways).

During those few seconds, it searches for the *previous* string whenever I click Find Next, before it belatedly realizes there's a new string that needs finding. I've attached a screen recording, if it helps. Also, here's my test document, if you'd like to try it out: https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=521059

This is mostly speculation, but I suspect the reason for the latency has to do with the default SearchAsYouType behaviour. Given how expensive you've said the search procedure is, then to avoid wasting time/effort on unwanted searches, the app has to wait for the user to stop typing first i.e. a reasonable gap between key presses, of said >2s.

The problem is, this means it also ignores *explicit* "Enter" requests to begin searching immediately, stubbornly deciding to wait for that timeout to elapse before it begins the new search. You can see this happen each time in the video, as I search for each string: "encrypt", "indication", "isoc".

So if this is at all correct, I guess the request would be for qpdfview to prioritize "Find Next" inputs to begin a new search immediately, and only rely on the timeout as a fallback. This should hopefully eliminate the latency, perceptibly at least.