Fix that in-page search is very slow in Chrome

[tanius]

Tested in Chrome 73 under Linux. When searching for words in the page using the standard Ctrl + F search box, both search and the display of search results is very slow. It took 10-20 s here.

It seems that the JavaScript animation is interfering with the (probably likewise JavaScript based) in-page search. This is not an issue with all these JavaScript particle animations but possibly just a configuration issue, as it does not happen over at the OpenVillage website.

[tanius]

Reportedly not an issue in Chrome under Mac OS X.

[tanius]

This turned out to be a performance-related issue introduced of triggered by the SingleFile browser extension.

When giving that extension access to the browser tab with a site that contains the particle animation and looking at the console in Web Developer Tools, there will be a message about SingleFile hooking the requestAnimationFrame method. And then >7 messages per second like this, all with timing values ≥50 ms:

    [Violation] 'requestAnimationFrame' handler took 97ms

When disabling access to such a site for SingleFile, Chrome's in-page search would work normal again and the message quoted above would not appear nearly as often (only sporadically, and this is admittedly a somewhat seasoned computer I'm working with).

So the in-page search dysfunction is not an issue that will be seen by many people – only by those that also have SingleFile or other interfering extensions installed, and by those with an even slower computer.

Still, technically this is an issue, as even in such slow environments the particle animation should not start to flood the browser's message bus system with all this 'requestAnimationFrame' handler took … stuff – which is probably what interferes with the in-page search function. It should instead simply decrease the targeted framerate from 1000 ms / 50 ms = 20 fps to a lower value that can be managed by the computer.

At the least we should report this upstream to the particle animation project we're building on.