Subject: timing is everything
From: WJCarpenter (bill-abisource@carpenter.ORG)
Date: Fri Mar 09 2001 - 16:55:04 CST
Perhaps there is someone reading this who is looking for a smallish
AbiWord project to do, but one that is visible enough to give a broad
feeling of satisfaction when correctly done. One such project would
be enhancing the background spell-checking by changing some of the
characteristics of the way it uses timers. (This has been on my to-do
list long enough that I know I'll never get to it.) This is not
critical path for anything, and it's not a problem so egregious that
we just *have* to have a solution for it pronto.
If you have on-the-fly spell checking enabled, the red squiggles for
misspelled words show up as part of a background task. The original
implementation had a timer that fired every 100ms, at which point the
spell checker worked on a chunk of text and then went back to sleep.
The spell checker takes these chunks of text from a queue. (A few
months ago, I changed this slightly so that the timers were 100ms from
end-of-work to beginning-of-work. This makes very little practical
difference in production, but in a DEBUG environment it was pretty
easy to get a timer firing in the middle of an assert caused by a
previous firing.)
For small documents and "just plain typing", this approach works quite
fine. In fact, if you are a casual AbiWord user, you may never have
noticed any problems with it. It can have the (annoyance) problem of
being too slow in a couple of different ways. If you load a large
document and then immediately scroll to the end, you will get there
before the spell checker does. (When you load the document, all its
text is added in chunks to the queue, and it just takes a while to
work them off.) If you have a large document and do "Ignore all" for
a word, it may be a while before the squiggles are turned off for
other instances of that word. (After "ignore all", all the text in
the document is again added to the queue so that the normal spell
checking process will erase the squiggles.)
So, in some cases you want spell checking to go faster. Your first
instinct might be to just change 100ms to something shorter, but that
would be a mistake. 100ms represents a reasonable compromise between
speed of completion of spell checking and responsiveness to user
inputs. If you make the number too big, spell checking is too slow.
If you make the number too small, at some point it interferes with
typing, scrolling, and menu stuff. It's hard to say what a good
number is on any particular machine with other stuff going on.
OTOH, if you knew that the user hadn't typed anything or done any
mouse clicks for a while, you'd want spell checking to scream ahead at
full speed, "occasionally" (in processor clock terms) checking for
user input events. When there have been recent input events, spell
checking should hold back a bit so that input event processing gets
more attention.
Changing the mix could be done by either (1) fiddling with the
interval between timer firings, or (2) fiddling with how much word
spell checker does per timer firing. My guess is that the best
solution might end up being a combination of both. Although this is a
relatively contained task, I think it will involve:
1. Some AbiWord code study, but not one of those "all over the map"
research projects. You would need to look at the on-the-fly spell
checking code, probably the XP abstracted timer mechanism (just to
make sure you understood what was going on), and the input event
processing code.
2. Some thoughtful design work.
3. Careful implementation.
4. Tweaking of the numbers involved, including feedback from people
running it under different environments (very important).
5. Accepting the congratulations of your companions for a job
well-done.
BTW, anyone looking around in the code for where the on-the-fly spell
checking is done could as well look around for "background checks".
Last summer, I generalized the spell checking timer loop to be able to
do other things, although there currently aren't any other things.
(My intent was to use it for smart quotes, but a simpler approach
occured to me after I had already implemented the background checks
changes.)
BTW II, if we had multi-threading, this would be taken care of for us
by making the spell check thread lower priority than the main thread
or whatever. At that point, we'd either be happy with it or powerless
to do anything about it. :-)
-- bill@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3
This archive was generated by hypermail 2b25 : Fri Mar 09 2001 - 16:54:16 CST