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 598322 - Find on page is painfully slow
Find on page is painfully slow
Status: RESOLVED FIXED
Product: epiphany
Classification: Core
Component: Backend
2.28.x
Other Linux
: Normal normal
: ---
Assigned To: Xan Lopez
Epiphany Maintainers
: 583194 605545 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-10-13 19:51 UTC by Wouter Bolsterlee (uws)
Modified: 2010-01-15 21:52 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
make search faster (2.30 KB, patch)
2009-12-28 14:37 UTC, Gustavo Noronha (kov)
none Details | Review

Description Wouter Bolsterlee (uws) 2009-10-13 19:51:10 UTC
The "Find on page" feature (Ctrl-F) is painfully slow in Epiphany 2.28. Especially on larger pages such as longer Wikipedia article, typing the first few letters totally blocks the UI. I reckon this is caused by the highlighting of all matches while typing. The effect is less noticable (if at all) after typing a few more characters.

Possible work-arounds/solutions:

 * Highlight only for search strings longer than a certain
   length (e.g. 3 characters)
 * Highlight after a short delay, so that typing a string
   doesn't cause browser UI hangs or flickering while the
   highlights are shown on screen

Perhaps a combination of these options would do: highlight after a delay (e.g. 500ms) for shorter search strings, and highlight immediately for longer strings (since those are less CPU intensive).So, if you just keep typing the search string at a reasonable pace you don't notice any slowdowns and you will see your search results directly after you're done typing, while for short search strings you would not notice the delay since it's slow anyway. This approach would effectively address the issues I'm experiencing.
Comment 1 Wouter Bolsterlee (uws) 2009-10-13 20:05:17 UTC
*** Bug 583194 has been marked as a duplicate of this bug. ***
Comment 2 Reinout van Schouwen 2009-12-19 15:21:21 UTC
Confirming.
Comment 3 Gustavo Noronha (kov) 2009-12-28 14:36:31 UTC
*** Bug 605545 has been marked as a duplicate of this bug. ***
Comment 4 Gustavo Noronha (kov) 2009-12-28 14:37:33 UTC
Created attachment 150494 [details] [review]
make search faster

While we know this needs fixing in WebCore, so that search can be done
asynchronously, and not block the UI, there are some strategies we can use to
alleviate the problem. One of them is not searching too early. Currently we
search for each character the user adds to the search toolbar. Adding a small
delay to search for longer strings improves this a lot. 

Try searching for 'media' in http://dev.w3.org/html5/spec/Overview.html with,
and without my patch.
Comment 5 Wouter Bolsterlee (uws) 2009-12-28 16:15:58 UTC
Gustavo,

Thanks for working on this. Does the patch you posted follow the approach I outlined in my initial report?
Comment 6 Gustavo Noronha (kov) 2009-12-28 17:22:07 UTC
(In reply to comment #5)
> Gustavo,
> 
> Thanks for working on this. Does the patch you posted follow the approach I
> outlined in my initial report?

Yes. I was thinking of something similar at the webkit hackfest, and end up implementing it.
Comment 7 Xan Lopez 2009-12-31 04:14:47 UTC
(In reply to comment #4)
> Created an attachment (id=150494) [details] [review]
> make search faster
> 
> While we know this needs fixing in WebCore, so that search can be done
> asynchronously, and not block the UI, there are some strategies we can use to
> alleviate the problem. One of them is not searching too early. Currently we
> search for each character the user adds to the search toolbar. Adding a small
> delay to search for longer strings improves this a lot. 
> 
> Try searching for 'media' in http://dev.w3.org/html5/spec/Overview.html with,
> and without my patch.

Not sure I understand the logic behind:

+		timeout = MAX(1000 / length, 100);

why do you want to wait more if the string is shorter? Also, I believe we should try to use the same values for timeouts in entries everywhere. I think we use 300ms elsewhere.

Other than that, looks good to me.
Comment 8 Gustavo Noronha (kov) 2010-01-03 21:30:46 UTC
(In reply to comment #7)
> Not sure I understand the logic behind:
> 
> +        timeout = MAX(1000 / length, 100);
> 
> why do you want to wait more if the string is shorter? Also, I believe we
> should try to use the same values for timeouts in entries everywhere. I think
> we use 300ms elsewhere.
> 
> Other than that, looks good to me.

The idea is to make it hard to search for 1/2 character strings unwillingly, while still having a more responsive incremental search for longer strings. This is essentially forgiving slow typers =). If you prefer I can make it 300ms, but this variable timeout works quite well for me =). Up to you, let me know and I'll update the patch.

Happy 2010!
Comment 9 Gustavo Noronha (kov) 2010-01-15 21:38:29 UTC
Pushed as bac714eab6253cf088761501117937e9b48bcea9. Needs webkit from trunk.
Comment 10 Gustavo Noronha (kov) 2010-01-15 21:38:58 UTC
Wrong bug =P.
Comment 11 Gustavo Noronha (kov) 2010-01-15 21:52:40 UTC
This was pushed as b573119b1338722ba9f6016b72064f6fcf681dfc, with the change Xan suggested.