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. 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... And do not forget to provide a solution for the Buffer loop of the explicit spell checker. > 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. 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. 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? 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(). 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. Stephan
