After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 557605 - allow launching the search manually
allow launching the search manually
Status: RESOLVED OBSOLETE
Product: evince
Classification: Core
Component: general
2.22.x
Other Linux
: Low enhancement
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on: 607907
Blocks:
 
 
Reported: 2008-10-23 13:14 UTC by Jean-François Fortin Tam
Modified: 2013-06-15 06:13 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description Jean-François Fortin Tam 2008-10-23 13:14:56 UTC
Perhaps a checkbox "[x] search as I type" in the search bar would be useful for performance-critical cases where you want to type the word fully before it starts searching?
Or, more simple, maybe evince should wait 1 second after the last keystroke before launching the search? Is there a bug report about this?
Comment 1 Emmanuel Fleury 2009-10-30 11:10:49 UTC
What would be the benefit of such a feature ?

I never had any problem with the "start to search as I type"...
Comment 2 Jean-François Fortin Tam 2009-10-31 14:07:13 UTC
Performance. On very large documents (for an extreme example, try this on "Office Open XML Part 4 - Markup Language Reference"), it will
- be slow to search because it starts again on each character you type
- waste power by loading the CPU/etc needlessly
- lower usability by adding jerkiness when the user types, and a general feeling of slowness
Comment 3 Travis Reitter 2012-10-30 16:34:49 UTC
Why not have Evince not start the search until the user stops typing for some very small interval (50 or 100ms?)? If the document isn't massive, this shouldn't slow down the time to results much. But if it is massive, this should have the benefit you're talking about.

This seems like a problem that just needs a simple heuristic, not another piece of machinery for the user to steer.
Comment 4 Germán Poo-Caamaño 2012-10-30 17:53:22 UTC
Is this bug report still valid with evince 3.6.0/poppler >= 0.20?

poppler has improved a lot since 2008/2009.  I just downloaded the PDF from
http://www.ecma-international.org/news/TC45_current_work/TC45_available_docs.htm
and I fail to see any CPU load increase in evince.

If I search for common words (say, present in the first hundreds of pages) is fast.  If I search a word that appears in the page 4202 (e.g. hueDir), it takes a while to find the word, but it has nothing to do "search as I type".
Comment 5 Germán Poo-Caamaño 2012-10-30 17:53:56 UTC
I forgot to mention that I tried with evince master (close to 3.6.0) and poppler 0.21.0.
Comment 6 Jean-François Fortin Tam 2012-10-31 02:31:57 UTC
Have you checked with, say, a Pentium 4 and 512 MB of ram or something? (just make sure you're not using a core i7 :)

I agree that there shouldn't be a UI toggle for this, simply a simple heuristic (maybe a timeout approach) to avoid doing "unneccessary" work - which, no matter how fast your computer is, is always a good thing.
Comment 7 Germán Poo-Caamaño 2012-10-31 02:58:05 UTC
Is this bug report still valid with evince 3.6.0/poppler >= 0.20?

Which version of cairo?
Comment 8 Michael Hill 2013-03-05 19:42:37 UTC
I am unable to reproduce this with evince 3.6.1 on ubuntu armhf (Nexus 7) using the OOXML pdf. The search speed seems pretty good.
Comment 9 Michael Hill 2013-03-06 00:04:12 UTC
(In reply to comment #8)
> I am unable to reproduce this with evince 3.6.1 on ubuntu armhf (Nexus 7)

poppler packages are 0.20.5.
Comment 10 Germán Poo-Caamaño 2013-06-15 06:13:01 UTC
Closing this as obsolete.

In spite of the performance improvements done with the render in newest versions of poppler, evince was emitting too many signals when searching.  This was fixed in 3.8.

See https://bugzilla.gnome.org/show_bug.cgi?id=694836 for more information.