On 05/10/2011 01:44 AM, Aryeh Gregor wrote:
On Mon, May 9, 2011 at 3:49 PM, Boris Zbarsky<bzbar...@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
