On 09/02/2010 02:19 PM, Stephan Witt wrote:
Am 02.09.2010 um 13:42 schrieb Abdelrazak Younes:
On 09/02/2010 12:13 PM, Stephan Witt wrote:
I could go back to the row based spell check and abandon the checker state of
paragraph.
But I decided to do the move from row to paragraph checking when seeing the
loop code in
Buffer.cpp which implements the explicit spell check with F7.
This code iterates word wise without knowledge of screen rows (of course). So
the
performance problem pops up here again.
Quite franqly I think the spell cache solution that I proposed a while back
would have resolved all performance problems. Pity that I don't have any time
to work on this...
I don't think so. Remember that the checking of the whole visible part of the
document word per word - even when it is done only once - is a problem with
apples native spell checker.
Well, if it is done once the slowdown will be once for one word. If the
word is found again in the document (and the probability is quite high)
then the spell cache will come in play without any help from the slow
spellchecker. Plus the fact that the spell cache can be saved to disk
for next time the document is opened.
It's not only about caching - it is about grouping as many words as possible
(at least a screen row) and checking longer strings per call.
If you open the document at first you have to check all of the visible content
as fast as possible. And on scroll down again.
That was the original problem. The word-wise checking...
I know all that but the cache as I said I think the cache would
attenuate a lot these problems if not eliminate them.
And do not forget to provide a solution for the Buffer loop of the explicit
spell checker.
Again, the spell cache will be even more beneficial in this case.
I am a bit uneasy with the whole paragraph based solution as I am raisonably
confident that it won't be as fast as the row based one for Aspell and Unspell
and the user experience will be worse I am sure.
I'm quite sure that my changes are a good move for Aspell and hunspell too.
The paragraph also caches the positions of misspelled words for them.
And it's very rare that you paint only one row. Mostly you paint all or big
parts of paragraphs.
When you create new lines sure but not when you write in a line, in this
case only a few rows (1 to 3) are redrawn most of the time. And as I
said, the spell cache will avoid the call to the real spellchecker
anyway... So even if you check the whole screen each time I reckon you
won't notice the difference. But this is only theory again :-)
Since every redraw triggers the spell checker in the past all contents was
checked again and again.
Now the first row to draw checks the complete paragraph (if needed) and all
subsequent rows of that paragraph use the cached results.
This seems a good move independently of the rest.
The next change of paragraph content invalidates the cached results... and the
redraw checks again.
Tracking content changing sounds nice in theory (this was my first solution for
the inline checking) but there are a lot of corner cases to catch as is
testified by the poor capability of Thunderbird and OpenOffice.
I don't know what problems Thunderbird and OpenOffice have. Could you mention
some?
These programs are only good at checking the currently edited contents.
They do not check the full visible text as we do. This is why the LyX
experience is much better.
And even at edition, often when you erase a char or use copy&paste, the
spellchecker doesn't work immediately you have to either wait or press
enter...
Also when you move to another paragraph without correcting your spell
mistakes, sometimes thunderbird or openoffice forget about them all...
very bad, really.
Did you try the patch? I cannot see where many corner cases can be.
Every change of paragraph contents goes through one of the public paragraph
interfaces - like insertChar().
No, think Copy&Paste, track change, paragraph fusion/deletion, etc.
There are a lot of corner cases.
If it's not possible to care for that then I think the count of interface
methods is too high.
When I find the time I'll compare the scroll performance of the current trunk
code of LyX un-patched and patched.
Please measure the edition performance as well, scrolling is not everything.
But all in all, don't get me wrong, I welcome your work a lot and I am
very glad that you do it. I am just warning you of some potential
problems. Your patch is also good in the sense that it could be used for
grammar checker in the future. But we would have to teach Paragraph
about sentences so that we send full sentences to the spell and grammar
checker, not the full paragraph contents. That would be very nice...
Cheers,
Abdel.
