It seems that you just disable the semantic parsing service but not semantic parsing itself.
No the semantic parsing service is alway enabled. I call either Document.SemanticParsingEnabled = false; before the appendtext loop and Document.SemanticParsingEnabled = true; after the loop completes. The call to SemanticParsingEnabled = true hangs for many seconds on a large document even with the service enabled.
However simply creating and showing all collapsable nodes can take some time too and this has to run in GUI thread.
This does not seem to be the case when the document is loaded normally or SemanticParsing is left on while appending text. It seems the semantic parsing service does all parsing and outlining in the background and will display the outlining after it completes with no UI hang. Just load a large xml document normally it will hang while simply displaying the highlighted text (lexing) but will become fully responsive with no outlining. Then after some time the outlining will appear with barely a stutter, this denotes the bulk of the work was done in the background and only the outline drawing was invoked on the main UI thread, and that seems to take very little time.
The outlining nodes are created based on the text currently available. If there is no matching end tag, there won't be a outlining node.
This seems odd, as though you are saying outlining might not work correctly if text is edited or appended quickly enough. Obviously this would not be the intention. I realize you can't have an outline node until the end tag exists, and appendtext may append an unclosed fragement, however a later call to appendtext will write the end tag. Any change to the document should require re-outlining, how would it be possible to have a complete valid xml document where certain tags are not outlined regardless of wether it was loaded all at once or appended in chunks. This seems like a bug to me.
As I said I would like to disable the outlining while the document is being loaded in chunks because I would imagine the service is starting a re-parse/outline on a every call to appendtext then cancelling and re-starting again on the next call wasting cpu time, but doing so is as bad as having the semantic parsing service off.
Silly question but did you start the semantic parser service? If it is off, everything will be done on the UI thread.
Its on I triple checked ;)
Even when it's on though, the parse results (built in the worker thread) call back to the main UI thread to set them on the Document.SemanticParseData property. That will trigger an automatic outlining run that occurs in the main UI thread.
Why would outlining occur on the UI thread? I know the drawing of the outlines must occur on the main thread but Outline.Add could be invoked in a loop on the background thread allowing messages to pump while new outlines are being added/drawn. This doesn't seem to do happen normally, Loading a large XML file in one shot seems to hang on text layout and lexing but then becomes responsive while parsing and outlining is occuring, once the service completes it's background work the outline appear with no perceptable UI hang. So somehow you guys are doing this.
For the second issue, if you change the outlining mode, it effectively calls Reparse() which causes another complete lex, parse, and outlining phase. That's why you see the slowdown there.
I suspect this is the actual issue. Setting Document.SemanticParsingEnabled or Document.Outlining to true is re-lexing which always occurs on the main thread from my understanding. Isn't everything lexed in appendtext or any document modification, this does not seem necessary why re-lex a document in this case? Outlining and parsing seem to happen in the service, setting them to true should simply wake up the service to do it's job just the same as if they where enabled and some text was modified in the document the lexing is already done.
Sorry but with the WinForms design, I don't think there is a better way.
I really think you guys should look at the incorrect outlining issue, if calling appendtext quickly against a document can result in incorrect outlining (and maybe parsing?) this seems like a bug. What if a user simply paste text to quickly? Also the setters on Document.Outlining.Mode and Document.SemanticParsingEnabled are doing some extra work on the UI thread that does not occur normally, again if a user types a key and modifies the document the service wakes up and parses without hanging the UI, setting those properties to true should essentially do the same thing.
I can put together a sample that shows the issues if that would help.