search

texstudio-org / texstudio

TeXstudio is a fully featured LaTeX editor. Our goal is to make writing LaTeX documents as easy and comfortable as possible.
http://www.texstudio.org/
GNU General Public License v3.0
2.79k stars 344 forks source link

Slow initial search operation in PDF viewer #2171

Open wmeyer48 opened 2 years ago

wmeyer48 commented 2 years ago

Environment

TeXstudio: 4.2.2 Qt: 5.15.2 OS: Windows 10 TeX distribution: miktex poor response as soon as I enter a character no movement in the PDF view when it is again responsive to my entry, the edit box content updates, but no search appears to commence How to reproduce Search in the PDF for anything. Every attempt I have made fails, as described. The viewer seems fine as viewer. It appears to be only the search which is broken.

Expected behavior

The PDF viewer should locate the first occurrence of my target word

Actual behavior

poor response as soon as I enter a character no movement in the PDF view when it is again responsive to my entry, the edit box content updates, but no search appears to commence How to reproduce Search in the PDF for anything. Every attempt I have made fails, as described. The viewer seems fine as viewer. It appears to be only the search which is broken.

How to reproduce

I have created a project using the Lorem ipsum generator, and it exhibits the problem. A zipped file is attached. TestKaoBook.zip

  1. Build the document.
  2. Go to the PDF Viewer.
  3. Go to top of document.
  4. Search: TYPE in the word: "placerat" (do not paste from the text)

The problem appears to manifest because the search is triggered as soon as a character is typed. As the document is about 470 pages, the search is large enough to take some time. I see no need for a screencast. The key to this seems to be the length of the document. And as it defaults to searching for a word, and the single character will not be found, then it will have to search the entire text before the edit box is again enabled. Once a search word has been entered, then the search action works fine. Likewise, if a word is pasted to the edit box, it works fine.

sunderme commented 2 years ago

searching is a poppler function. It is performed blocking, so the txs stops until that function returns. If it needs to search through a lot of text, that may take some time. It is not simple to change that to non-blocking, but if someone wants to tackle this...

by the way, your example does not lead to extended search times here. It gets "stuck" when the word is not part of the text and txs needs to go through all the text.

wmeyer48 commented 2 years ago

I did update the title to refer to a slow "initial" search. As you note, if the word is not present, the search will necessarily cover the entire document. But typing a single character with word mode checked is, in some text patterns, the same issue. Once the search pattern is stable, moving to the next instance is quick, and not affected.

Workaround is to uncheck word mode until search pattern is fully entered. I see the problem as not so much a question of blocking as of how the operation is triggered. As built, a change in the edit box is acted upon immediately. That really makes it an incremental search in its behavior.

Yes, making the search non-blocking (threaded) would eliminate the issue, but at substantial development cost. An alternate approach could be to stop any search when a change is entered in the edit box, and to require the user to click a search button to initiate the search. That may seem less elegant, but would work consistently, whatever options are selected, and would be much easier to implement.