On 05/10/2011 08:33 PM, Adam Shannon wrote:
On Tue, May 10, 2011 at 06:49, Olli Pettay<olli.pet...@helsinki.fi> wrote:
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
On the desktop I wouldn't call that an "acceptable" solution;
requiring 200ms+ just to spell check words on a page?
That 200ms+ is only for the case when web page wants to do its own
spellchecking and has reasonable large block of text to check. In
the common case when the web page relies fully on the
browser's native spellchecking, no events would be fired.
But yeah, 200ms is quite a lot anyway.
-Olli
