GNOME Bugzilla – Bug 598322
Find on page is painfully slow
Last modified: 2010-01-15 21:52:40 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.
*** Bug 583194 has been marked as a duplicate of this bug. ***
Confirming.
*** Bug 605545 has been marked as a duplicate of this bug. ***
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.
Gustavo, Thanks for working on this. Does the patch you posted follow the approach I outlined in my initial report?
(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.
(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.
(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!
Pushed as bac714eab6253cf088761501117937e9b48bcea9. Needs webkit from trunk.
Wrong bug =P.
This was pushed as b573119b1338722ba9f6016b72064f6fcf681dfc, with the change Xan suggested.