- From: Olli Pettay <Olli.Pettay@helsinki.fi>
- Date: Tue, 10 May 2011 14:49:11 +0300
- To: Aryeh Gregor <Simetrical+w3c@gmail.com>
- CC: Boris Zbarsky <bzbarsky@mit.edu>, public-webapps@w3.org
On 05/10/2011 01:44 AM, Aryeh Gregor wrote: > On Mon, May 9, 2011 at 3:49 PM, Boris Zbarsky<bzbarsky@mit.edu> wrote: >> This does mean firing tens of thousands of events during load on some pages >> (e.g. wikipedia article edit pages).... Maybe that's not a big deal. > > If that's too many events, couldn't the browser optimize by not > spellchecking words until they scroll into view? I imagine that might > not be terribly simple, depending on how the browser is designed, but > maybe tens of thousands of events aren't too expensive anyway. I > don't know, up to implementers whether it's doable. > > I'm assuming here that there's effectively no cost if no one's > registered a spellcheck handler, so it won't penalize authors who > don't use the feature. > > Just a quick test on Nokia N900 (which is already a bit old mobile phone) using a recent browser: dispatching 10000 events to a deep (depth 100) DOM (without listeners for the event - for testing purposes) takes about 3 seconds. If there is a listener, the test takes 4-5s per 10000 events. If the DOM is shallow, the test without listeners takes about 1s, and with a listener about 2-3s. This is just one browser engine, but based on my testing on desktop, the differences between browser engines aren't in order of magnitude in this case. On a fast desktop those tests take 50-200ms. So, tens of thousands events doesn't sounds like a fast enough solution for mobile devices, but would be ok for desktop, I think. -Olli
Received on Tuesday, 10 May 2011 11:49:37 UTC