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. -OlliReceived on Tuesday, 10 May 2011 11:49:37 UTC
This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:19 UTC